Rust is a systems language. To be a systems PL, it is very important not to hide underlying computer memory management from a programmer. For this reason, Rust pushes programmers to expose many details that would be otherwise hidden in more high-level languages. Examples: pointers, references and associated stuff, memory allocators, different string types, different Fn traits, std::pin, et cetera.
Rust is a static language. This is better explained in my previous essay “Why Static Languages Suffer From Complexity”. To restate, languages with static type systems (or equivalent functionality) tend to duplicate their features on their static and dynamic levels, thereby introducing statics-dynamics biformity. Transforming a static abstraction into its dynamic counterpart is called upcasting; the inverse process is called downcasting. Inside push_handler, we have used upcasting to turn a static handler into the dynamic Handler type to be pushed to the final vector.
C and C++ are both systems languages and static typed languages (I don't know of any systems language which is dynamic typed) and don't feel to me so hard.
C# has "pointers, references and associated stuff, memory allocators, different string types" as features but it is at the same time a higher level language and you make use of those features only when you need to deal with low level stuff, no pain implied.
So, to me, these reasons don't quite explain why "Rust is hard".
Maybe in C++ it's easier to get a program to compile, but it's dramatically harder to make sure you've checked all the boxes you're supposed to check to make sure your code is safe and complies with best practices.
For instance, consider the rules of 5 [1]. There are so many rules like this in C++, so much complicated stuff you're supposed to know to write anything at all, and much of this is just _accidental_ complexity: it's just there for historical reasons or language design reasons that in retrospect don't make much sense.
Rule of 5 was a C++11 thing, maybe even mainly a C++03 thing.
Your complaints about C++ have aged badly. C++20 is not the same language as C++11, which was not the same language as C++03.
Rust's complexity is rapidly approaching C++'s. In 5 years, if Rust hasn't fizzled, it will get there. Only being used to it will make it seem any simpler.
> C++20 is not the same language as C++11, which was not the same language as C++03
This is not a good thing. In fact, it's a shockingly bad thing. C++ is basically 40 years old, and still every few years the C++ community feels like, "OK, now we know how to get C++ right; yeah the old C++ was a mess, but now we just need to add these 12 new features and it'll all be good."
Unfortunately many of the problems with C++ are due to mistakes in its early design. It was wrong from the beginning.
I've been programming Rust for 6 years. C++ for over 20. I'll take Rust every day of the week and twice on Sunday.
If it is bad that C++ evolves, then it is worse for Rust, which has been evolving much faster, trying to catch up. It is still just barely possible Rust could avoid fizzling. For that to happen, it will need to change enough so that the many, many more people who reject than embrace Rust, as it is today, choose differently tomorrow.
Evolution is necessary to stay relevant; the only alternative is stagnation. If your language or your code of five years ago does not embarrass you today, it only means you haven't learned anything new.
Rust is indeed changing pretty fast. But it's new. And most of the design decisions work well together. The language as of 2015-2016 was a reasonable language, and the changes since then have very rarely been of the form "This earlier design was a mistake, and we need to fix it all."
But C++, even in its pre-template 1980s form, was already full of wrong decisions (granted, many of those decisions were done for compatibility with C).
Including headers is the wrong way to share code. C-style macros are a bad idea. The whole copy constructor idea instead of move semantics, and then an explicit clone function when you need that, was the wrong idea. The complex mess of various constructor types. The friend mechanism to control access is complicated and unnecessary - why not just a simple module system? The complicated inheritance system - virtual, public, protected, private inheritance - what is this goop? The implicit conversions between integer types has caused countless problems. The language is extraordinarily hard to parse.
All of these things (and plenty more) I feel perfectly comfortable saying are just outright bad.
In Rust, all the basic language stuff... the module system, the traits, trait objects, the mechanism for defining new types as enums or structs, even the borrow checker... it's all fine, and it works well together. It's definitely not perfect, I have my gripes. But when I write C++ I can never forget for one second that it's a conglomeration of baffling design decisions and one attempt after another to patch over prior mistakes. I never feel anything like that with Rust.
> If your language or your code of five years ago does not embarrass you today
I mean I get where you're coming from with this, but I would say if an entire community that's been around for 40 years can look back every 5 years and always say "the way we were doing things 5 years ago was completely wrong," that's a serious problem.
In just another few years, if Rust does not fizzle, you will feel the same way about code in Rust as it evolves and improves.
But how C++ was coded to older Standards was not wrong at the time. That code was chosen judiciously according to features of the language as it existed then, and our understanding of it and our world.
Changes in languages are not random. Every last change in each new C++ Standard was in response to recognition that code would be better using the proposed change. Failing to use the new features as intended, after, would amount to choosing not to write code better.
Rust started at a snapshot of how problems of coding were understood at one time. Our understanding today and the world we program for have changed markedly from that time. Both will continue changing. What is good Rust will also change as the world, our understanding of it, and the language all change.
> In just another few years, if Rust does not fizzle, you will feel the same way about code in Rust as it evolves and improves.
I've written fairly extensive amounts of code in C, C++, Rust, Python, Java, OCaml, Haskell, Clojure, Common Lisp, Scheme, and probably some others that aren't coming to mind right now. All of these languages except Rust have been around for decades (and I guess Clojure is about a decade and a half). My opinion of these languages vary. They all have their warts. Some of these languages I don't particularly like. Some of them are complicated, some are fairly simple.
But C++ is the only one where I feel like the basic features of the language are actively working against me. It's the only one where I feel like such a huge portion of language design decisions were utterly baffling and wrong.
IME some members of the C++ community can be fairly insular. They just can't see how things are done outside their world. You expect me to believe that I'll eventually feel the same way about Rust as I do about C++, but I know that's unlikely to be true because C++ is the only language that I feel this way about.
Rust is a systems language. To be a systems PL, it is very important not to hide underlying computer memory management from a programmer. For this reason, Rust pushes programmers to expose many details that would be otherwise hidden in more high-level languages. Examples: pointers, references and associated stuff, memory allocators, different string types, different Fn traits, std::pin, et cetera.
Rust is a static language. This is better explained in my previous essay “Why Static Languages Suffer From Complexity”. To restate, languages with static type systems (or equivalent functionality) tend to duplicate their features on their static and dynamic levels, thereby introducing statics-dynamics biformity. Transforming a static abstraction into its dynamic counterpart is called upcasting; the inverse process is called downcasting. Inside push_handler, we have used upcasting to turn a static handler into the dynamic Handler type to be pushed to the final vector.
C and C++ are both systems languages and static typed languages (I don't know of any systems language which is dynamic typed) and don't feel to me so hard.
C# has "pointers, references and associated stuff, memory allocators, different string types" as features but it is at the same time a higher level language and you make use of those features only when you need to deal with low level stuff, no pain implied.
So, to me, these reasons don't quite explain why "Rust is hard".