> Rust Ownership and Lifetime rules aren't really that hard to learn.
What’s hard is not to learn the rules themselves, but to build things under the constraints of these rules. That turns out to be very different, because even though the rules are simple, they have knock-on cumulative downstream effects on the process of making software. My guess is it doesn’t fit well with how most people think, and especially the order in which a problem is broken down (such as front-loading ownership decisions).
> What’s hard is (...) [building] [code] under the constraints of these rules
Good point - I have to admit that, for example, the single-mutable-reference rule in Rust did force me to keep restructuring my code differently than I used to in other PLs and I did struggle with it to an extent.
It doesn't automatically mean, however, that Rust is (literally) "harder to learn than other PLs". It is possibly the question of whether "a programming concept is hard to learn since it cannot be painlessly brought over from previous experience" or "a programming concept is hard to learn since it is hard to understand in itself".
Yeah. It also depends on what we mean by learning a language. For most people, I assume we feel comfortable when we can achieve day to day tasks. You could have other metrics though, such as learning how to write code that is free from certain problems, like safety and data races.
The amount of problems that Rust moves from the “runtime and unit test” domain to compile time errors is unprecedented in mainstream languages, and also that those errors are binary pass/fail showstoppers. Empirically, I’ve found that programmers coming from C/C++ are much more happy about that than other backgrounds, presumably because they are aware of the pains of having those issues appear at runtime. However, it’s also important to understand that there are a huge amount of use cases where those problems can be solved “good enough” with GCs and other runtime safeguards, which then can give other benefits that outweighs the downsides.
What’s hard is not to learn the rules themselves, but to build things under the constraints of these rules. That turns out to be very different, because even though the rules are simple, they have knock-on cumulative downstream effects on the process of making software. My guess is it doesn’t fit well with how most people think, and especially the order in which a problem is broken down (such as front-loading ownership decisions).