Which C++? I know of classic C++ (98), then C++11 which I've used, but now there's C++14, C++17. C++20(?) which all seem to have very different features... I'm glad C++ is improving, but eh it's as tricky as HTML5/ES5 to keep up to date on.
My new job is to port a company forward to C++11, FML.
The claim at the top of the page is that "The ratings are based on the number of skilled engineers world-wide, courses and third party vendors." However, the details show that it really is just a single search term across a variety of search engines. Maybe they used to have an intern read the classifieds at the back of the Communications of the ACM or something.
You can bring your C++98 code and compile it with the latest compiler in C++20 mode and it should still work.
This allows you to upgrade (and learn) incrementally. You can slowly incorporate new features into an old code base.
https://static.googleusercontent.com/media/research.google.c...
I will give a nod to the other poster who pointed out automatic tools. They are often worth running on everything, but they only fix a fraction of the things that a sane developer with 20/20 hindsight starting over would do differently.
I'd say C++98 + C++17 is easier to deal with than C++98 + Rust.
Keep in mind that these are largely relatively useless or now replaced features so any incompatibilities should be both few and far between and relatively easy to fix.
All languages evolve & change, not just HMTL5/ES5. I worked at Apple when Swift was first rolled out & the language today is very different & unrecognizable to me from the one that exists today. The original code won't even compile today (not necessarily terrible if the automated conversion tools are 100% perfect).
Java is on a ~1yr cadence for the past 3 years (used to be 2 before that except for Java 7, 8 & 9 which had a longer lead time & likely not coincidentally is the time period that saw tremendous growth in C#) Swift is on a ~1 yr cadence with major language changes still happening. Upgrades are managed by automatic tooling. Will be interesting to see if Apple can sustain this long-term (every problem gets magnified a lot with time if you're growing). Rust is on a ~~1 yr cadence although they've come up with an interesting way to land major language changes & improvements into the language (release process rather & I can't recall if they use automated tooling).~~*
The problem of evolving languages isn't being ignored but it's a hard challenge. However, any language designer who ignores new up & coming concepts in language design is relegated to repeat the mistakes of C++ and Java which stagnated for long periods & let other languages capture large amounts of market share. Market share = how healthy the ecosystem for that language is & whether new projects get started in it. So if you just try to solve that problem first you'll end up never getting off the ground because you won't have an ecosystem around you to drive investment of time & money from users of that language.
I think you're just seeing the reorientation to a faster release cadence in the industry. Rather than waiting many years to deliver on larger features (Python3, Perl5), there's a more regular process to continuously ship smaller subsets of them in a usable form to get feedback, amortize the cost of adoption, & address any issues sooner. This also makes you more competitive in terms of users adopting your language for new projects. This obviously does have an externality cost as there can be less QA & bake time for code. Those can be mitigated with automation. Design defects can be addressed sooner & those are valuable because they're the pain-points for your user base.
I wish C++ actually delivered faster but given that there's 3 mainline compilers & a bunch of ancilliary ones, it's going to stagnate & die in favor of Swift or Rust which only have 1 shared reference compiler that everyone uses. It's also why projects like PyPy never grow beyond a small niche if you make that kind of choice. I'm on the side of Swift and Rust models - in C/C++ to support different platforms I need different compilers. This means in any non-trivial project I have to add different per-compiler workarounds to language interpretation or feature set (even clang's attempts to pretend to be GCC or MSVC don't work out well & you end up having to adjust your project to actually be aware of it).
* EDIT: Corrected below. Rust is on a 6-week cadence with a 3-year roll-up of the supporting material & an interesting way to support mixing and matching code from different versions.
Which cadence are you talking about? We have releases every six weeks, and editions roughly every three years, but not a yearly cadence that I can think of right now.