[bjorn2k]

I agree that c++ is complex, but remember that while trying to update the language the standard committee is trying not to do breaking changes. If you can do a greenfield implementation like rust, you don't have the baggage of an installed base, yet. If you compare c++ to a language that is also around for more that 25 years it starts to make more sense why it is complex. Add to that, that it started as an extension to c, which is the reason why it became popular in the beginning. Also, zero-cost run-time abstractions.

It is whatever you give priority design-wise, and if you look at what is important in c++ (zero-cost runtime abstractions, control of the resulting code), then ending up with something as complex as the c++ language is hard to prevent.

[IshKebab]

Yeah by keeping backwards compatibility they avoided something like the Python 2/3 mess which I would say is worth the effort and cruft.

[jVinc]

Looking at the current programming language space, it honestly doesn't look like the Python 2/3 issue hit them that hard in the long run. And while it wasn't popular it might have been the right way forwards. Python is one of if not the most rapidly growing language. In large part due to the data-science movement which for anyone I've talked to is based on Python 3. I still occasionally talk to 2.7 proponents, who explain to me that they need to have this and that to handle all the complicated edge cases and problems in dealing with bytes vs. strings... Issues that you just don't encounter at all in python3.

If I had the choice of having a C++2020 with absolutely no backwards compatibility but a greatly cleaned up language or having yet another step down the path it's heading now, I'd chose the former even if it breaks backwards compatibility. But the language is going to follow the developers and they want to continue down the path where they get to explain again and again and again the intricacies and delicacies of rvalue semantics, exotic template meta-programming and what-ever the next big thing is going to be. All the while we seemingly still don't even have a clear road-map for providing simple modules.

I was enthusiastic back when C++11 hit and it felt like a great big push going on in the language development, I had the feeling that things were really going to take off... but now it feels like it just died out, and now there's nothing that really gets me exited about the future of C++. I'm worried It's going to get more and more complex and less and less used.

[oblio]

I know I'm in dangerous territory here, but what if the C++ community, as in committee, compilers, etc., pull a Javascript strict mode?

Basically subsequent C++ compilers provide the possibility of some subset of C++ which is considered modern. Then files can be marked with it, at which point the C++ compilers reject deprecated idioms. Over time this should take over, I think most of the JS in the wild is now using strict mode.

I can't be the first person to think of this. There must be a reason something like this hasn't gotten traction.

[gpderetta]

The header inclusion model (where you will be textually including hundreds of thousand lines of random code in a translation unit) doesn't make it easy to have version flags.

Also many of the issues are intrinsic to the way the language has evolved (the template compilation model for example), it is not just a matter of deprecating a few features here and there (although that might help)

[lowbloodsugar]

Headers are what need fixing first. They are why I would never consider using C++ for any new project and avoid jobs that require maintaining C++ code. C++ is the steam power of computing and keeping legacy monoliths running doesn't do anyone any favors. That shit should have been piece-by-piece rewritten by now.

[carlmr]

You're forgoing all of the sweet cash that C++ legacy maintainers will make in 20-odd years. Like the COBOL people right now.

[bjorn2k]

I also would like to drop backwards compatibility in favor for a clean simple language, because I happen to write completely new functionality. If you ask yourself the question: "Do I want to break backwards compatibility in 2020?", then that same question could have been asked in 2003. Which would mean that the language lost traction (at least that is my opinion), because I could not recompile my old code and therefore I keep using the old before C++2003 compiler. So, the reason that it is popular, _is_ because it takes care of installed base and does not break existing code (or at least minimizes breakage).

[gpderetta]

Exactly.

There have been plenty of from-scratch languages that are designed as a better C++. Many have died, of those left no one has yet gained significant traction [1].

It is not clear why yet another an incompatible language would be better just because it happens to be called C++. The effort would be better spent on improving one of the existing alternatives.

[1] Plenty of newer languages have had breakaway success, but no language that is meant to be a full C++ replacement has yet. D has passed peak hype without a breakout. Rust might still make it, we will see.

[Gibbon1]

> If I had the choice of having a C++2020

Would be nice to just do a fork and you either pass -std=c11 or -std=c20.

[lou1306]

On the other hand, I find Python 3 much more predictable/less astonishing than 2. The jump was definitely a mess, but judging by the continuous spread of the language it seems to have paid off in the long term.

[zbentley]

Both extremes (preserving backwards compatibility at the cost of maintainability/complexity, and abandoning back compat at the cost of existing code breakage) are bad. One may be worse than the other, but they're both bad options. The minimum-pain solution is somewhere in the middle.