I'd sooner master rust, which seems to have a lot of buzz around it. the world has needed a low-level prog-lang that's less painful than C/C++ for a while, rust may have enough merit to displace a lot of C/C++ dev - I just hope it gets well standardised, in such a way that C++ isn't.
Both Rust and Go (big in China) are worth looking at. Unless you're doing games programming C++ is neither C/ASM (which is popular for hardware) nor Java/C# (popular for business software) or PHP/RoR/Java (popular for web back ends).
Plus when you learn C++ you don't have to learn one language, it is more like learning four or five as they completely re-invented the language every time a standard ships. This might sound good, except a lot of these constructs are a pain in the butt to intermingle.
Rust is better than C++, but most people work in legacy applications. And C++ ecosystem has a lot more stable libraries, frameworks and very active community.
Furthermore, I'm not just talking about the existence of a standard, but the complexity of the standard (C++is v. big), and also how much that standard restricts, and hence results in conformal, predictable code.
You mean C++03, C++11, C++14, C++17? Or something else?
If you mean those, I fail to see the problem. The language isn't dead, so it's not static, and it evolves over time. Publishing a new standard every few years is the only way to keep all compilers aligned, rather than each going off in its own "with extra features!" direction.
Yes, those. The differences between standards aren't trivial, and often the older standards have to be maintained.
The standard already has lots of features, including a turing-complete sub-language.
It is difficult to write code to standard (nothing that works, but is undefined either), that is safe, no segfaults, memory issue, secure, and all within a practical budget/timeline.
Just being able to reason about the code more easily helps, or make strong assumptions (e.g. about safety).
You're reducing the argument here. qualitative arguments (true/false) over quantitative (to what degree).
Your argument is similar to: "Hitler is bad, but no one if perfect" - does that mean than anyone not perfect is equivalent to Hitler?
Moving on; to focus on python it's not difficult to know the handful of changes between, say, python 2.5 and 2.7, nor to understand them. py3 is different, and the fork caused a lot of controversy, there is still resistance to py3. There is a python-2-to-python-3 tool (could any such thing practically exist between C++ versions?), but it's not perfect.
A language like Java almost suffers from trying to remain backwards compatible, yes a) the feature is nonetheless appreciated, and java is heavily used and praised in 'enterprise' b) Java tends to make breaking changes rarely, and only when necessary - can the changes between C++ specs be described the same?
From the point of view of the ISO, my understanding is that they consider it to only have a single standard, with newer versions completely subsuming the existing one. I would actually argue that if C++ has a standards problem, it's that major revisions (1998, 2011, 2017, etc) are not treated as being distinct standards.
