The Two Factions of C++ (2024)

>“We must minimize the need to change existing code. For adoption in existing code, decades of experience has consistently shown that most customers with large code bases cannot and will not change even 1% of their lines of code in order to satisfy strictness rules, not even for safety reasons unless regulatory requirements compel them to do so.”

But the major players do seem to be happy to replace their C++ code with Rust.

Perhaps it's time to ease up on the backwards compatibility. Especially in the era of AI.

Should have a (2024) annotation so far as I can see (haven't finished reading the article but it seems to be about events which have "just happened" back then)

also at the time this is what HN wrote about it: https://news.ycombinator.com/item?id=42231489

To be fair to the committee, upgrading C++ compilers is already a chore, even with the changes as small as they are. Would you rather spend time updating your lambdas because they changed how capture works (a real breakage not long ago), or doing something of actual value? The only reason we finally updated from Python 2.7 to 3 was that the OS vendors dropped it, but it was effectively a waste of time.

That aside, I don’t understand why ABI breakage is a big deal. There’s probably a good reason, but ABIs are already so fragile, you can’t mix and match different compiler versions anyway, or even the same compiler with different flags. Why does it matter if setting -std29 or whatever breaks ABI when -fno-rtti does the same?

The C++ committee should really stop adding esoteric features for library writers and focus on stuff for normies. Tooling is one as the article says, or how about finally getting Networking TS? This is probably the only mainstream language left that doesn’t have even basic networking support.

I was deeply saddened by the vote the article refers to that effectively excluded Sean Baxter's Safe C++. It felt like a push that prevented tabling the solution at all. If Safe C++ had been debated on its merits, that would be one thing, but this seemed (to me) to prevent ever getting to that point. Who knows if that was the intent: the result is what disappointed me.

In my view, one of the major compiler vendors needs to take on Safe C++ and start supporting it... with refactoring tooling to get a codebase there. Because as this article says, tooling is key.

It's a committee, many people are involved, all with different opinions, but any decision requires consensus.

Why would anyone expect big broad changes? And historically, whenever they did happen anyway through forced compromise, they resulted in failure because they were not consistently implemented.

The only way that works is small compatible and iterative changes.

> Google supposedly significantly lowered its participation in the C++ development process, and instead started to work on their own C++ successor language.

Did they decide to keep things as is or rewrite in Rust with LLM assistance in the couple years since this article? Carbon seems to have gone nowhere.

Try building google opensource projects. They'll be mostly broken on your own toolchain.

Very interesting summary of facts and quotations with conclusions. I would say there are even more camps than the two mentioned. Personally I think C++98 and Qt5 just worked and were good enough for all purposes, and C++ since has become an ever moving target with a lot of incompatibilities between compilers. Chasing for the ever latest version of the language and compilers is very expensive and enervating. I prefer how they solved this e.g. in the Ada community; they take their time for the release a new standard version, and until then, most compiler vendors have already updated their products and there was relevant experience with the new features long before the new standard was passed. In computer science, it seems to be a law of nature to keep "improving" good things until they become unusable and people walk away. In C++ I did so; I have a few C++11 code bases (some back ported from newer versions), but most are C++98/03; I even made a fork of Qt5 (LeanQt) with my own build system (BUSY) which is less work to maintain than continuously chasing new compiler/tool incompatibilities among platforms.

There is a natural tendency for all programming languages to want to both retain backwards compatibility and also accumulate new features, eventually outgrowing the original design. C++ is obviously well past this point.

If this was a code base rather than a language specification, then this would be the time to refactor, but with a programming language you've got a world full of code, compilers and tools, and the resistance to change is massive.

One of the few success stories of a language refactoring and dropping backwards compatibility is Python 2 -> Python 3 (a 10+ year struggle). What might be considered as a failure case is Perl 5 -> Perl 6, where resistance to change caused the migration to Perl 6 to be so slow that effectively Perl 5 won, and the language itself became obsolete.

So, be careful for what you wish for - C++ certainly needs a refactoring, but whether it could survive it is another question, especially now since backwards compatibility is what is keeping it alive in the face of competition, and it's not at all clear going forwards what the impact of AI on programming languages is going to be.

> it’s at least a bitter awareness of the fact that the industry doesn’t care to refactor existing code

Refactoring working, terrain-tested code?!?

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Previous HN discussion here (https://news.ycombinator.com/item?id=42231489); 2024-11-24, 554 points, 653 comments

This is why I'm building Quxlang.

C++ cannot evolve easily without breaking backwards compatibility.

I started Quxlang because I saw the writing on the wall for C++. Doesn't mean C++ isn't good, but it has issues and needs improvement.

Somehow I managed to implement working modules, C++ doesn't seem to have that yet, although the C++ build system is horribly broken.

We'll have to see how it compares when it's more complete and ready to use. I don't have oop/inheritance yet which is also important for a C++ alternative.

(2024)

Past discussion (653 comments): https://news.ycombinator.com/item?id=42231489

I think that the steering committee currently considers that backwards compatibility has higher priority compared to strict memory safety. When the priorities will inverse then solutions will be found.