The Two Factions of C++ (2024)

In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#. I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad, because I swear I spent 2 days trying to setup CMake to get Skyrim modding setup, and in the end, I had to tap out and begrudgingly had Codex do it.

The other major problem for C++ is that correct C++ basically looks like nonsense, because the committee insists on pushing dangerous footguns that nobody sane would ever use in normal codebases through yet takes their sweet time with adding basic functionalities like pattern matching or even "print", which is somehow finally added in C++23. Worse still, nothing is ever really allowed to be removed/deprecated from C++, so you have decades of accumulated syntax debt that nobody is allowed to actually fix.

I think the biggest issue with C++ is that despite the fact that 90% of the language just should not be used in any normal code, period, there really is nothing that can replace C++ in its niche of high performance, low-level systems level programming. There is a good language buried underneath C++ somewhere, it's just that nobody has taken the time to extract it.

>“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

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.

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.

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

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

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

Refactoring work, terrain tested code?!?

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

(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.

> 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.

(2024)

[flagged]