> The language itself is way too complicated. The learning curve is steep. Improvements are made (e.g. lifetime elision) but they don't flatten the curve.
I disagree that the improvements that have been made to the language ergonomics haven't changed the slope of Rust's learning curve, and I'm not entirely convinced that the language features are the totality of the problem when it comes to the difficulty of picking Rust up by experienced developers[2]. I also have the further belief that the language itself is not the only thing that affects the learning curve of a language. The available libraries, documentation, tooling, platform support, and the surrounding community all affect how easy to learn a language is, and as importantly, how likely people are to stick around.
> Macros are very hard to debug and understand. Which is even more of an issue when they are used by dependencies and something goes wrong.
I agree. In their current incantation. Long term Rust will have other ways of declaring and using macros. proc_macros is one post-1.0 change, but multiple people in the team have their targets aimed beyond that feature to provide compile-time code expansion that are easier to learn, understand, declare, use, and debug than macro_rules and proc_macros.
> Error messages don't help.
Things got much better in the 2018-2019 period for macros error messages in particular, but they are still a long way off from what I'd personally like to see. It is a hard problem that I am intimately familiar with. There's one particular change I would like to implement in the next year (tracking spans of macro_rule macro arguments through operations on the macro body, regardless of operations on them, like if you call foo!(bar) and the problem is with bar, the underline should point at bar and not to both foo!(bar) and in the definition of foo where bar was used), but improvements in this area are non-trivial and take time.
> Macros are powerful but can hide too much magic.
True, this is a problem not only for crates that rely heavily on macros but also for ones that rely heavily on complex trait bounds. I would personally wish crate writers to exercise some restraint on how complex their APIs are considering also how difficult to understand it is what went wrong when using them wrong, but I have no authority to force anyone to do things the way I'd like to and cope by 1) leading by example and 2) slowly but steadily improving diagnostics for patterns used in the wild.
> Plus, they are a language of their own.
They are. As alluded to but not explicitly said earlier, macro_rules where a placeholder for the 1.0 release. They are in every way an MVP, scheduled to be replaced at some point[1]. The thing is that they work "well enough™️" so there hasn't been a quick push to replace them, and we wouldn't want to rush a new way of doing something you can already do and get stuck with two subpar features. And proc_macros have their own host of issues to deal with, from wrapping your head around writing Rust code to generate Rust code, dealing with the AST, finding the right crates to use, learning how to use the available hooks to provide reasonable error messages, etc.
> "Why doesn't have this structure any methods?" "Oh, they are hidden in traits, provided by other crates, themselves leveraging other traits from other crates". "Still, it doesn't compile. Why?"
Agree, and that can be even exacerbated by the use of Derive and proc_macros, which can generate the impl for the "hidden" trait in a way that rust-analyzer and rg won't find them.
> "Oh, because of that generic that requires traits from yet another crate that are only available when some Cargo features has been enabled". Once again, this is difficult to follow and debug.
This is one of the mentioned "hard problems" that diagnostics could help with but nailing the experience down to make it "enjoyable" (or even bearable) require changes and coordination between rustc, cargo, and in some cases but likely not this one in particular, crate writers.
> Zero-cost abstractions are great, but in Rust, they are overused.
In parts of the ecosystem they absolutely are. I don't think there's anything about the language itself that encourage their overuse, I think it is more of the "new toy" effect: "Oh! Neat feature! And this lets me make this problem unrepresentable! NEAT! Let's use it! (Wait, what does it look like when someone misuses this? OH, NO!)".
> This makes the language less accessible, but also constantly causes dependency issues due to incompatible versions.
> Rust is powerful but it is not optimized for developer happiness.
Again, I disagree, but I can see your point of view. IMO Rust optimizes for debugability: the behavior of the code is always laid bare, which leads to verbosity (although it might be partially hidden behind Derives or macros, there is no "implicit" behavior). I find that this brings me joy when working on production-ready projects.
> Fighting the compiler brings anger, not joy.
It saddens me to hear that and would love to take any extra feedback in order to mitigate the anger it brings you.
> Sure, the compiler may have good reasons to complain. But as a developer, I'm happier and more productive when code immediately runs, even if that means having to fix bugs later.
How would you even find out about the bugs later? There's always the possibility of a buggy branching code path is never run, until it is, months after the fact.
> This is from a happiness view, not from a security perspective. But eventually, happiness turns into productivity.
I migh guess part of the issue is the old "make as many pots as possible in the allotted time" vs "take the allotted time and make a single great pot" experiment: more, faster iterations yields better quality in the same amount of time. This is a perfectly valid complaint about how fussy rustc can be, but the target is for rustc to be more akin to a pair programmer: "Hey! You forgot this trait bound here so that it matches what you're calling. Add it over there and that should do it."
> It's too late to fix this. But now that Rust demonstrated that memory safety and speed were not incompatible, future system languages will feel obligated to provide the same properties, maybe by using mechanisms similar to Rust.
And I've gotten to the part I actually wanted to answer to :)
What do you feel would get in the way from making Rust easier to use? I agree that there are ergonomic related things that could be done that won't because they would affect some of the use cases that Rust targets (like embedded, kernels or databases), like auto-cloning or auto-boxing which would make the language feel way higher level than it currently does, but I think there are lots of other things that could be done (thinking of the match pattern ergonomics work done some time back where you don't have to write & in patterns nearly as much now) that would make the experience of writing code nicer without sacrificing any of the project's stated goals.
> So, my prediction is that Rust will slowly be replaced by new safe languages that will be more accessible, more productive, more stable, and bring novel ideas of their own. But Rust will have made history no matter what.
If Rust's impact is nothing else but improving the larger ecosystem through the indirect impact of raising the bar for whatever comes after, then it will have been worth it.
[1]: https://github.com/rust-lang/rfcs/blob/master/text/1584-macr...
[2]: https://youtu.be/Z6X7Ada0ugE?t=705 Transcript of the relevant excerpt:
> I have the unsubstantiated theory that experienced developers have a harder time than less experienced developers when learning Rust. You need to forget a lot of constructs that work well enough in the languages you already know because they introduce things that go against the single owner enforcement that Rust has, whereas somebody with less experience will simultaneously accept restrictions as "just the way it is" and not seek out more performant constructs that can be much harder to understand or implement. Rust has a curse (it has many, but this one is critical): inefficient code is generally visible. Experienced developers hate to notice that their code is inefficient. They will recoil at seeing `Arc<RefCell<T>>`, but won't bat an eye at using Python. I know because I have the same instinct! This makes it much harder to learn Rust for experienced developers because they start with the "simple Rust code that will work but is slightly inefficient" and in an effort to improve it they land squarely in parts of the language they haven't yet developed a mental model for.