3 ms·

Build times are a bit slow, but runtime is just as fast as what you'd get doing the same thing in C or C++. Development time is absurdly faster, though, since

Build times are a bit slow, but runtime is just as fast as what you'd get doing the same thing in C or C++. Development time is absurdly faster, though, since you don't spend much time debugging annoying language-design bugs, and can focus entirely in your code's logic.

fidotron 2y ago
> focus entirely in your code's logic That is if your code satisfies the borrow checker out of the gate, fine. I have seen Rust book authors get derailed for years by apparently simple seeming projects that do not.
- wiz21c 2y ago
  When the borrow checker doesn't let you compile, it's either because it can't understand your code (and that's unfortunate and infuriating and costs a lot of time to figure out), either because your code won't be absolutely safe (and so you'd better listen to the BC instead of complaining about it). rust can be very frustrating because it forces you to think up front at a level of safety you may not be used to. That's the issue. I do fairly simple things with rust (i.e. just some threads, no complex data structure (but complex program nonetheless)) and rust safety helps me a lot in reducing the number of bugs.
- orphea 2y ago
  It's been a while when I worked with Rust, but when I did I felt like people are misusing Rust references. IIRC, they are supposed to be short-living, i.e. you get a reference, you do your thing with it and then you get rid of it asap. For actually long-living references Rc<> should work pretty fine?
- chuckadams 2y ago
  Looking at Rust from the outside, I see the borrow checker as something I might slam into all the time, but if it’s all static, then it’s strictness I can get used to; “if it compiles, it works,” right? But now I’m reading that there’s a dynamic borrow checker too, and I’m left wondering: does rust really crash at runtime if two scopes reference the same field at the same time? That sounds like the kind of infuriating footgun as NPEs in a non null-safe language. Does it really work like that?
  - steveklabnik 2y ago
    The borrow checker is fully static. There are types in the standard library that, if you use them, do runtime checks. If you run afoul of those checks, then yes, you’ll get a runtime failure. (The primary example being RefCell<T> linked in the article linked there, yes.) These types are not super common in Rust code generally, but they do exist and are useful at times.
  - desdenova 2y ago
    The "dynamic borrow checker" is called a RefCell, and it's a footgun you have to explicitly point at your foot and pull the trigger, not something you'd randomly stumble upon. It's something you'd use very situationally, after you really considered all your options and found out you couldn't do it by writing normal code instead, and this is a very rare situation. Think of them like Python's metaclasses.
- steveklabnik 2y ago
  > I have seen Rust book authors get derailed for years by apparently simple seeming projects that do not. What are you referring to here?
- desdenova 2y ago
  Just learn how to program without mutating things unnecessarily, it isn't that hard.
daghamm 2y ago
I think the jury is still out on the development time. Sure, once you get your code to compile things may go faster. But getting there is not always easy.
glass-z13 2y ago
>Development time is absurdly faster That definitely sounds like you have never made/contributed to anything non trivial that's made in Rust. Development time is significantly slower for any non toy project where the problem domain hasn't been solved/the person/s don't have experience with.
hatefulmoron 2y ago
> Development time is absurdly faster, though, since you don't spend much time debugging annoying language-design bugs, and can focus entirely in your code's logic. I don't mean to be dismissive, but if this was really true we'd all be writing TLA+ specifications/Coq proofs before finalizing our Ada SPARK implementations. In reality, static analysis only improves development time if time_lost_to_debugging > time_lost_to_arm_wrestling_compiler, and in my experience that's not always as common as one would like to believe.
- desdenova 2y ago
  If you're wrestling the compiler, you should improve your programming skills before trying to analyze programming languages.
  - hatefulmoron 2y ago
    Ah yes, I'm sure that all of your Rust code compiles the first time :^).
FpUser 2y ago
>"Development time is absurdly faster, though, since you don't spend much time debugging annoying language-design bugs," Utter BS. I mainly developing in C++ at the moment (not limited to this single language though) and I do not find myself debugging "language-design bugs". I do not design libraries hence my code and set of used language features is of course simpler. I tend to avoid esoteric code and do not have habit to shove everything into new templates.

fidotron 2y ago

> focus entirely in your code's logic That is if your code satisfies the borrow checker out of the gate, fine. I have seen Rust book authors get derailed for years by apparently simple seeming projects that do not.

wiz21c 2y ago
When the borrow checker doesn't let you compile, it's either because it can't understand your code (and that's unfortunate and infuriating and costs a lot of time to figure out), either because your code won't be absolutely safe (and so you'd better listen to the BC instead of complaining about it). rust can be very frustrating because it forces you to think up front at a level of safety you may not be used to. That's the issue. I do fairly simple things with rust (i.e. just some threads, no complex data structure (but complex program nonetheless)) and rust safety helps me a lot in reducing the number of bugs.
orphea 2y ago
It's been a while when I worked with Rust, but when I did I felt like people are misusing Rust references. IIRC, they are supposed to be short-living, i.e. you get a reference, you do your thing with it and then you get rid of it asap. For actually long-living references Rc<> should work pretty fine?
chuckadams 2y ago
Looking at Rust from the outside, I see the borrow checker as something I might slam into all the time, but if it’s all static, then it’s strictness I can get used to; “if it compiles, it works,” right? But now I’m reading that there’s a dynamic borrow checker too, and I’m left wondering: does rust really crash at runtime if two scopes reference the same field at the same time? That sounds like the kind of infuriating footgun as NPEs in a non null-safe language. Does it really work like that?
- steveklabnik 2y ago
  The borrow checker is fully static. There are types in the standard library that, if you use them, do runtime checks. If you run afoul of those checks, then yes, you’ll get a runtime failure. (The primary example being RefCell<T> linked in the article linked there, yes.) These types are not super common in Rust code generally, but they do exist and are useful at times.
- desdenova 2y ago
  The "dynamic borrow checker" is called a RefCell, and it's a footgun you have to explicitly point at your foot and pull the trigger, not something you'd randomly stumble upon. It's something you'd use very situationally, after you really considered all your options and found out you couldn't do it by writing normal code instead, and this is a very rare situation. Think of them like Python's metaclasses.
steveklabnik 2y ago
> I have seen Rust book authors get derailed for years by apparently simple seeming projects that do not. What are you referring to here?
desdenova 2y ago
Just learn how to program without mutating things unnecessarily, it isn't that hard.

daghamm 2y ago

I think the jury is still out on the development time. Sure, once you get your code to compile things may go faster. But getting there is not always easy.

glass-z13 2y ago

>Development time is absurdly faster That definitely sounds like you have never made/contributed to anything non trivial that's made in Rust. Development time is significantly slower for any non toy project where the problem domain hasn't been solved/the person/s don't have experience with.

hatefulmoron 2y ago

> Development time is absurdly faster, though, since you don't spend much time debugging annoying language-design bugs, and can focus entirely in your code's logic. I don't mean to be dismissive, but if this was really true we'd all be writing TLA+ specifications/Coq proofs before finalizing our Ada SPARK implementations. In reality, static analysis only improves development time if time_lost_to_debugging > time_lost_to_arm_wrestling_compiler, and in my experience that's not always as common as one would like to believe.

desdenova 2y ago
If you're wrestling the compiler, you should improve your programming skills before trying to analyze programming languages.
- hatefulmoron 2y ago
  Ah yes, I'm sure that all of your Rust code compiles the first time :^).

FpUser 2y ago

>"Development time is absurdly faster, though, since you don't spend much time debugging annoying language-design bugs," Utter BS. I mainly developing in C++ at the moment (not limited to this single language though) and I do not find myself debugging "language-design bugs". I do not design libraries hence my code and set of used language features is of course simpler. I tend to avoid esoteric code and do not have habit to shove everything into new templates.