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)
>“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.
Rochus
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.
show comments
mgaunard
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.
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.
show comments
cherryteastain
> 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.
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
>“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.
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
> 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-...
Try building google opensource projects. They'll be mostly broken on your own toolchain.
(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)