> 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.

It's been a while when I worked with Rust, but when I did I felt like people misuse Rust references. IIRC, they are not supposed to be short-living, i.e. you get a reference, do your thing and get rid of it asap. For actually long-living references Rc<> should work pretty fine?

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.

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?

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.

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.

> I have seen Rust book authors get derailed for years by apparently simple seeming projects that do not.

What are you referring to here?

Just learn how to program without mutating things unnecessarily, it isn't that hard.

> 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.

If you're wrestling the compiler, you should improve your programming skills before trying to analyze programming languages.

Ah yes, I'm sure that all of your Rust code compiles the first time :^).

>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.

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.

>"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.