Safe Rust doesn't have classes, inheritance, copy constructors, move constructors, header files, preprocessor, textual substitution macros, code executing before main(), exceptions, global variables, pointer arithmetic... Looks radically simpler to me.
I agree that Rust is simpler than C++ and I think a lot of people mean that Rust isn't easier (up front). Given how new and different it can be, that makes sense.
And by the way, Rust does have pointer arithmetic.
It's not clear to me that either is simpler or easier. The big point of Rust is really memory safety, not ease of use or simplicity.
Now, that "everyone" there has a bunch of social consequences, like you're going to see a bunch more diversity in Rust's community than we've traditionally seen in this sort of endeavour. But it also means technically there's work put in to actually deliver on the slogan by making it easier for everyone to use the language.
This is how Rust has those excellent compiler diagnostics. That's not an accident, it's part of "empowering everyone". Experts could manage with a compiler that outputs terse errors like "Syntax error, line 14" but that's not going to empower everyone.
Rust has a heck of a lot of features, but it’s got nothing like the “too perfect forwarding” problem of the language behaviour just being plain hard to predict.
Rust lacking some of these makes it a somewhat unfriendly language to write libraries in.
You can have multiple inheritance. You can have as many levels of partially implemented, partially abstract classes as you like provided you eventually have a concrete class, and these abstract classes can have member data. You can have static methods, which I've seen abused as namespaces so often. You can have static methods and non static ones in a class hierarchy. Finally you can mix templates into this.
In an ideal world the developers of a project in a company would collaborate to keep this from getting out of control and enforce a relatively consistent philosophy. However in practice people have their quirks and specific not always rational views, and programmers are in general not always the best at dealing with other people, programmers included.
So a strong personality is determined to do it one way and refactors a bunch of code to their liking, and on and on, and now a variety of features have been used in different ways.
No language is immune to this as it is fundamentally a human problem, but taking out features generally helps. Since we can get by without inheritance most of the newer languages have done away with it.
It is also important to separate C++ the language from its standard library.
As C++ the language has modernized, it has dramatically reduced the lines of code to express a given thing. And the more modern way of expressing the thing has stronger type safety, more flexibility, and better composability. Things that used to require a lot of template metaprogramming magic to pull off are now clean one-liners. Particularly in C++20, which is probably the biggest step-change since C++11, metaprogramming is simultaneously much more powerful and much more readable. A lot of code that used to be written is now metaprogrammed. Previous use cases that required C macros largely have native C++ equivalents at this point.
The major issue that makes C++ seem complex is the standard library, which was largely designed and written for legacy versions of C++. If you use the standard library heavily, it tends to want to be used in the style of C++ for which it was originally written. If you built a standard library for C++20 from first principles, it would look quite different from the one we have. Hence the proliferation of non-standard "standard" libraries for C++.
That said, I like the idea of rewriting old C++ code with modern C++. That'd be also a good way to learn modern C++ in a practical way and having legacy code serves well for this context ;-)
Any examples for this? My knowledge stopped at boost and I guess there are more.
Not sure if you've missed this, but this is a number one reason many consider C++ absurdly complex. To actually know C++ is to know many different similar languages based on the year the code was written. C++20 is very different than C++03 as noted. Now compare this with C, or Go, Java, etc. which in comparison have barely changed.
I think that Carbon is not meant to be 100% backward compatible at least at this point, so they can iteratively try to smooth the rough edges of the language.
it's kitchen sink language.
choose what features you want.
choose your own style. you wanna do OOP | DOP suit yourself.
that versatility is why C++ is unmatched in terms of where it's deployed.
The Github Page[1] says this: "The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax."