> when I open a Rust project I cannot understand what the hell is going on (...)
> Then you have to learn to map errors, boxing them, dyn dispatching (...) So it's not all "ownership and lifetimes".
I definitely see where you are coming from when it comes to PL syntax density and PL surface area in general, Rust or no Rust. I will probably surprise you when I admit that even though I have been coding C++ for decades and I learned Rust without any major problems, I lost my small personal war to become comfortable with the modern, newcomer-friendly, memory-managed... Swift. Yes, that great-for-your-first-PL Swift. I started out as a Swift aficionado, but with time I started hating the language exactly due to the fact that "I [opened] a [Swift] project [and] I [could not] understand what the hell [was] going on". The language was just too bloated and idiom-based. I gave Rust a shot and I learned Rust much more effortlessly, perhaps due to Rust's "consistency" and "predictability". My point: it might be that any modern PL can get pretty dense and broad due to the necessity of handling imperative, functional, generics, async, multi-threaded, a capable standard library, etc., while it might be just a myth that Rust is "harder to learn" than other modern PLs. For me personally, Rust "ownership and lifetimes" turned out to be easier to learn than Swift "feature set", but it might be just me.
> The worst part (for what learning regards) is that Rust doesn't forgive.
Yes, but this is the whole point of Rust! Rust tries very hard to shift bug detection from runtime to compile-time and the only way it can do that is by strictly enforcing a set of sometimes complex rules at compile time. However, it is common occurrence that it takes tenfold more time to find a bug in a piece of code (especially bugs related to unexpected memory mutation or multi-threaded memory access) than to write that piece of code in the first place. So, wrestling the Rust compiler is "a calculated cost" designed to be worth it in the end.
I definitely see where you are coming from when it comes to PL syntax density and PL surface area in general, Rust or no Rust. I will probably surprise you when I admit that even though I have been coding C++ for decades and I learned Rust without any major problems, I lost my small personal war to become comfortable with the modern, newcomer-friendly, memory-managed... Swift. Yes, that great-for-your-first-PL Swift. I started out as a Swift aficionado, but with time I started hating the language exactly due to the fact that "I [opened] a [Swift] project [and] I [could not] understand what the hell [was] going on". The language was just too bloated and idiom-based. I gave Rust a shot and I learned Rust much more effortlessly, perhaps due to Rust's "consistency" and "predictability". My point: it might be that any modern PL can get pretty dense and broad due to the necessity of handling imperative, functional, generics, async, multi-threaded, a capable standard library, etc., while it might be just a myth that Rust is "harder to learn" than other modern PLs. For me personally, Rust "ownership and lifetimes" turned out to be easier to learn than Swift "feature set", but it might be just me.
> The worst part (for what learning regards) is that Rust doesn't forgive.
Yes, but this is the whole point of Rust! Rust tries very hard to shift bug detection from runtime to compile-time and the only way it can do that is by strictly enforcing a set of sometimes complex rules at compile time. However, it is common occurrence that it takes tenfold more time to find a bug in a piece of code (especially bugs related to unexpected memory mutation or multi-threaded memory access) than to write that piece of code in the first place. So, wrestling the Rust compiler is "a calculated cost" designed to be worth it in the end.