It's a multipurpose, statically compiled and standardized language. I don't think its complexity is a problem. Simplicity in a industrial level language like C++ can't really be expected.
I'd say C++ is a for a multitude of uses, it allows to do things precisely and well, but it has a cost, the one of learning how to use it.
1) There are many other alternatives than C++ that will cover a lot of use-cases. You don't always "need" to use C++, unless you have precise needs all the time, or don't want to have another language interact with your code.
2) You can still use C++ and avoid complex features, or just use C.
3) The language keeps evolving, and I think it's great that companies are working towards an ISO standard. Few languages have that. Maybe the language will be a little easier to use in the future.
C++ is complex in many ways which are unrelated to its core functionality. For example: most vexing parse, integer promotions, conflated language features (classes provide records, polymorphism, namespacing, encapsulation), header files, vector<bool>, the grammar is insanely complicated, et cetera. C++, like Common Lisp, is a standards effort which places more value on preserving the ability to run existing code than it does on removing language warts. Tools are now appearing like clang-format, clang-modernize, ReSharper, etc., but the equivalent tools have been available for other languages for quite some time now because those languages don't have the same complexity just at the syntactic level that C++ does. For example, Python has "2to3", and this was made with far fewer resources than "clang-modernize". Sure, C++ has richer semantics. But the syntax really is a maze, and if it weren't, we could have had our tools longer ago.
Well many of those issues are inherited from C, and Stroustrup has stated that compatibility with C was an absolute prerequisite otherwise C++ would have been stillborn. Given its position now, it's impossible to say that he was wrong, although I wonder if certain things could have been tidied up that would only have compilation-failed really bad code (e.g. it annoys me that you can pass a floating point value where an integer is expected).
While that's true, a lot of the complexity is self-inflicted. C++ tries to define syntaxes for its features in a C style which cripples a lot of features in unnecessary ways. For example, classes being kinda like a C struct instead of a separate syntax altogether.
Honestly, even Objective-C is better in this regard because the Objective-C parts are well separated from the C parts instead of feeling wedged-in.
I would argue that's "better". As a result, Objective-C feels like an alien language for a C programmer. Although to be fair I don't think a core C programmer would move to either C++ or Objective-C unless (s)he has to (iOS support or legacy code). I think it is the same reason why C++ developers are not moving to Go anytime soon.
I'd gladly move to a language that has the syntactic sugar of C++ (STL, lambdas, modules, and many other things) without the complexity (templates, inheritance, polymorphism).
Go and Rust seems to have weird syntax differences with C and I don't understand the utility of those. The go function syntax looks a little bit hairy.
C++ isn't evolving; it's just accumulating features. That's a crucial difference. The amount of harmful patterns you can accidentally use just keep on strictly increasing.
MY "observation" is that your "observation" cannot be trusted because you're being "unfair" in your "characterization" of C++'s new features as being the negative phrase "accumulating features" rather than "evolving" despite the idea that "evolving" implies getting "new features".
Maybe the language will be a little easier to use in the future.
this is always double with C++.
At one point, it most definitely is easier to use now already than pre-C++14 or 11. Lots of those additions really make me enjoy using it (even more:) and often lead to less code which does the same while still not being harder to understand (often even better to understand) and having the same performance.
However, because of the backwards compatibility there still is cruft around which does make it harder to use because you basically need to know how to use it or in most cases that you shouldn't use it at all. Ideally one just wouldn't need to spend time / 'brain resources' on that kind of stuff. Simple example: I can still use std::auto_ptr. I won't because there are much better alternatives. I can still use std::tr1::shared_ptr. I don't, and I know what it is when I see it. But for a newcomer or slow learners this is just utter nonsense: need to figure out wtf tr1 is, why it exists, what to do with it, and so on.
Couldn't these things just be deprecated? As in, never removed because of compatibility, but when compiling you would get warnings about using features no longer 'best practices', and maybe there could be a switch for 'modern c++' that would turn use of these features in errors?
Yes that would be ideal - in practice it is also not extremely hard as most of these things aren't baked in to the compiler/linker but can be solved with (a lot) of #ifdefs. The harder part is likely getting such thing into the standard: decide what will be deprecated and what not.
It's a multipurpose, statically compiled and standardized language. I don't think its complexity is a problem. Simplicity in a industrial level language like C++ can't really be expected.
I'd say C++ is a for a multitude of uses, it allows to do things precisely and well, but it has a cost, the one of learning how to use it.
1) There are many other alternatives than C++ that will cover a lot of use-cases. You don't always "need" to use C++, unless you have precise needs all the time, or don't want to have another language interact with your code.
2) You can still use C++ and avoid complex features, or just use C.
3) The language keeps evolving, and I think it's great that companies are working towards an ISO standard. Few languages have that. Maybe the language will be a little easier to use in the future.