You don’t have to know about exception safety, move semantics, meta-template higgery jiggery, or the 30 years of cruft that C++ has accumulated.
Good riddance.
Good riddance.
1. Exception safety becomes "catch_unwind." You might object that nobody cares about that, but major C++ codebases (Google, LLVM, Mozilla) don't care about exceptions; they are built with -fno-exceptions.
2. Move semantics in C++ are annoying, and so is the borrow checker. In Rust you get hit by things like "this code is fine here, but you aren't allowed to refactor it into a function" because there's no interprocedrural visibility into struct fields.
3. Meta-template higgery-jiggery is real and bad in C++, but has a mirror in Rust. With C++ duck-typed generics you write dumb code that does the thing, and then you can refine it with hilariously awful techniques like SFINAE. In Rust you're googling higher-ranked trait bounds before you can even write the thing. What does `for` do again? I think "strongly-typed language, duck-typed generics" is a bit of a sweet spot and C++ has lucked its way into it.
4. "30 years of cruft" means things like "I speak C preprocessor" which is practical. C compat is why C++ is both so awkward and so successful. There's no smooth ramp from C++ to Rust, the way there was from C to C++; that's a choice and maybe the right choice but it has a price.
With concepts in C++20, you get to choose whether templates are duck-typed.
C++ will still be used heavily when Rust is buried 6 feet under and HN moves to the next hype language.
If you're working on a substantial C++ codebase you probably do, actually.
Eh, all these "different string" are different because... Well, they have different requirements. Path is not a normal string, it has platform-dependent implications, String/str are UTF8 strings, the byte-esque string have raw bytes, etc. I know I'm being brief, but I hope the differences I'm trying to illustrate are clear, and why it makes sense for these to be different types.
> arcane borrow checker workarounds
You often end up with these in portable/cross-platform C++ or in performance sensitive C++ code. Also, if you've not burdened yourself with OOP-style thinking and adjust your expectations to the fact you're not writing C++ anymore, but a different language, you'll have an easier time learning Rust. All that said, what you call workarounds is probably idiomatic to Rust developers. And even in the most pathological case of workarounds, the resulting Rust code will be much more succinct than any back-breaking efforts to make C++ readable/correct/performant (two of which you get for free in Rust; sans some complicated domains). Like, as examples: just working with std::variant is a nightmare and requires grotesque constructs with visitors patterns (and often lambdas), std::option is a joke that's marginally better than a raw pointer, etc.
> RefCell complexity,
It's no worse than just working with borrowing, and it's not that often you'd use this anyways.
> massive async cruft
Yes, you have a point here, and everyone's aware of this. And people who have ideas in the community about how it can be addressed can easily participate in the discussion and design process if they desire. Whereas C++ is designed by a committee of people who only barely still use the language in the real world (I know there's exceptions, but alas).
Also, if we got tooth for tooth, C++ has an abundance of more complexity than Rust does, and a lot of it isn't even obviously (hence can be dangerous, or just ruin your day/productivity)
have fun living your life pretending all strings are of the same type. spoiler alert: it's the wrong kind of fun. it's a bit easier if you're from a native English speaking country, but only until you get blown up by utf-8 (if you're lucky) in production.