I think the problem here is how hard people have to fight.
How about take a step back, and view the language as a completely noob, you may found many complexes in the language is unnecessary.
For example, in the sample code, you can found many #[macro_use]s, they are needed to import macros to the local scope. But hey, why I can't just `use slog::{!macro_name, something_not_macro}`?
Well, the doc said: "macro definitions aren’t namespaced within modules like function definitions are. To prevent unexpected name clashes when using external crates ....".
But why macro is not namespaced then? Why user has to learn "the macro is not namespaced" so they have to #[macro_use]? Why not just implement it in a more intuitive way?
Rust team need to consider this: How many complexities can be completely removed from the language, while maintain it's final goal (be a fast and safe system language).
> Confidence when doing systems-level programming. For old hands, Rust’s guarantees mean you can spend less of your time and attention on avoiding pitfalls, which makes it possible to reach for more ambitious goals. For newer systems programmers, it means a shorter path to being able to start writing production code.
> This second point is worth emphasizing. In traditional systems programming, there’s just an intense amount of discipline you need to learn in order to write production code. Because the discipline takes so long to master, and the stakes of slipping up are crashes and security vulnerabilities, most people will only trust seasoned veterans of systems programming to ship production C++ code. But with Rust, you don’t have to master this discipline to start shipping production code; you know the language has your back.
As far as I can read, it states the purpose of the language is correctness, and developer productivity?
Yes, but _while_ being as fast as C or faster (e.g. without aliasing issues).
With those two goals they do not imply they'd sacrifice speed for them. They had stated elsewhere that speed and no-cost-abstractions are extremely important for Rust.
If they stop fighting after they learn, then no, it's not a problem with the language. It's the very definition of learning.
Now, the language might be harder to learn than others, and that might be a problem in itself.
But not just because people have to struggle at first "in order to become productive with it". That's true for any language that brings anything new to the table.
>The argument of pass by reference, or borrowing is that it’s more performant than cloning by default. In general, computers are getting faster, but systems are getting more complex.
Rust was not created to piggyback on "computers getting faster".
It was created to be as fast as possible.