[saghm]

> So many times I've tried to do something in Rust the old fashioned way, the way I have always done things, and been stopped by the compiler. I then investigate why the compiler/language is being so anal about this trivial thing I want to do.. and yup, there's a concurrency bug I never would have thought of! I guess all that old code I wrote has bugs that I didn't know about at the time.

This is also my experience. I've had dozens of times over the years that I've been confused about why Rust does something a certain way, but I don't think I can recall a single one where I didn't end up finding out that there was an extremely good reason for it. That's not to say that in every one of those cases, the design choice Rust made was the only reasonable one, but in the cases where it wasn't, the situation always ended up being more nuanced than it appeared to me at first glance, and what I would have originally expected would have implicitly made a significant tradeoff I hadn't considered.

I'm having trouble finding it now, but years ago someone had a quote that ended up getting published in the language's weekly newsletter that was something like "Rust moves the pain of understanding your program from the future to the present". It's extremely apt; most of the difficulty I've seen people run into when trying to program in Rust ends up being that they're forced to consider potential issues that in other languages they could have ignored until later, and then would have had to debug down the line.

[adastra22]

That’s a very good quote.

There’s a handful of pain points that the Rust model does impart which are not fundamental. For example, unsafe code is required to get a mutable borrow to two different fields of a struct at the same time.

But really that’s the only example I can think of offhandedly, and I expect there are not many in total. Nearly all of the pain is merely the trouble of thinking through these issue upfront instead of kicking the can down the road.

[saghm]

The only other one I can think of is kind of poor ergonomics around "self-borrows"; it's a lot less common than I've felt the need to mutably borrow two fields from the same struct independently, but there have very occasionally been times where I've realized the simplest way to structure something would be to have one field in a struct borrow another. This is somewhat hard to express given the need to initialize all of the values of a struct at once, and even if you could, there are some complications in how you could use such a struct (e.g. not being able to mutate field `a` safely if it's borrowed by field `b`). Overall though, the things that Rust prevents me from handling safely because of its own limitations rather than them being fundamentally unsafe are quite rare, and even with those, they tend to be things that I would be quite likely to mess up in practice if I tried to do them in a language without the same safety rails.

[byko3y]

>the things that Rust prevents me from handling safely because of its own limitations rather than them being fundamentally unsafe are quite rare, and even with those, they tend to be things that I would be quite likely to mess up in practice if I tried to do them in a language without the same safety rails.

Any language with GC can handle complex links between object, including mutable object. Like Erlang/Elixir, JS, Go, etc. You message implies runtime-less language, but majority of practically employed languages are runtime-full.