> C++ mostly still echoes the diversify of hardware architectures and runtime environments out there
It doesn't though, or at least none of those echoes are why C++ is complex. Here are some examples of unnecessary complexity.
The rules of 3/5 exist solely due to copy/move/assign semantics. These rules do not need to exist if the semantics were simpler.
Programmers need to be aware of expression value categories (lvalue, rvalue, etc). These concepts that most languages keep as internal details of their IRs are leaked to error messages, because of the complex semantics of expression evaluation.
SFINAE is a subtle rule of template expansion that is exploited for compile time introspection due to the fact the latter is just missing, despite the clear desire for it.
The C++ memory model for atomics is a particular source of confusion and incorrectness in concurrent programs because it decouples a fairly simple problem domain and rules into (arguably too small) a set of semantics that are easy to misuse, and also create surprisingly complex emergent behaviors when misused that become hard to debug.
These are problems with the language's design and have nothing to do with the hardware and systems it targets.
The thing that bugs me about this topic is that C++ developers have a kind of Stockholm syndrome for their terrible tools and devex. I see people routinely struggle with things that other languages simply don't have (including C and Rust!) because C++ seems committed to playing on hard mode. It's so bad that every C++ code base I've worked on professionally is essentially its own dialect and ecosystem with zero cross pollination (except one of abseil/boost/folly).
There is so much complexity in there that creates no value. Good features and libraries die in the womb because of it.
SFINAE in 2025 is only reasonable in existing old code, or people stuck in old compilers.
Since C++17 there are better options.
Despite all its warts, most C++ wannabe replacements, depend on compiler tools written in C++, and this isn't going to change in then foreseeable future, based on the about two decades that took to replace C with C++ in compiler development circles, even though there is some compatibility.
It doesn't though, or at least none of those echoes are why C++ is complex. Here are some examples of unnecessary complexity.
The rules of 3/5 exist solely due to copy/move/assign semantics. These rules do not need to exist if the semantics were simpler.
Programmers need to be aware of expression value categories (lvalue, rvalue, etc). These concepts that most languages keep as internal details of their IRs are leaked to error messages, because of the complex semantics of expression evaluation.
SFINAE is a subtle rule of template expansion that is exploited for compile time introspection due to the fact the latter is just missing, despite the clear desire for it.
The C++ memory model for atomics is a particular source of confusion and incorrectness in concurrent programs because it decouples a fairly simple problem domain and rules into (arguably too small) a set of semantics that are easy to misuse, and also create surprisingly complex emergent behaviors when misused that become hard to debug.
These are problems with the language's design and have nothing to do with the hardware and systems it targets.
The thing that bugs me about this topic is that C++ developers have a kind of Stockholm syndrome for their terrible tools and devex. I see people routinely struggle with things that other languages simply don't have (including C and Rust!) because C++ seems committed to playing on hard mode. It's so bad that every C++ code base I've worked on professionally is essentially its own dialect and ecosystem with zero cross pollination (except one of abseil/boost/folly).
There is so much complexity in there that creates no value. Good features and libraries die in the womb because of it.