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)
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.
I understand the issue about the ever-moving target etc., but almost fifteen years later do you really believe C++98 is better than C++11 without move semantics and decent smart pointers? I remember working with Qt5 and C++98 and yes, it was productive, but it was also a mess of intricate object ownership.
I'm critical about some choices made with C++20 and after, like the mess that modules are, and the too-little-too-late ranges library. C++26 is also a joke imho. But on the other hand, working with std::optional and (in C++23) std::expected is so much better than without. The thing is nobody forces you to use every single feature of a new standard, but I would not recommend ignoring very good tools just for the sake of it.
For all of my projects it is good enough. C++11 onwards has a few advantages, but I don't need them. Moving ownership between containers to avoid allocations was possible with the standard library even before C++11, and Qt offered "implicit sharing" which has a similar effect without syntax changes and incompatibilities. Even with my C++11 projects (e.g. https://github.com/rochus-keller/eigen/) I had to take care still in 2024 which feature not to use on MSVC because it didn't work or behaved differently. I never have any ownership issues and I implement large compiler projects with different AST and IR layers. All my projects still compile with https://github.com/rochus-keller/leanqt/ on all platforms. I would never trade a tiny language advantage with a whole world of dependability issues. One day I will revive and refactor GCC 4.7 to get a cross-platform C++98 with parts of 11 compiler just written in C, then latest all of my software is buildable "from first principles".
PS: it's funny I wrote my comment three days (and not an hour) ago.
> Moving ownership between containers to avoid allocations was possible
That's not the biggest upside of move semantics. You can't safely express smart pointers without move semantics. They tried with std::auto_ptr, and it didn't work.
C++26 will allow billions of lines of pointless serialization boilerplate to finally be deleted, adding the basic reflection functionality that most other languages have had for decades.
Reflection is a joke. De/serializing arbitrary C++ structs is ill-defined. When you need serialization, even lots of it (e.g. silly JSON), I think you're better off writing your own framework where you can be clear about data formats and transformation rules.
Yes, C++26 reflection is nice, but also extremely complex to understand and use well. The rest of C++26 is the usual series of too-little-too-late additions. Meanwhile I’m still waiting for pattern matching to become a thing (a proposal has been discussed for ages)
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.
A big problem is that "consensus" for WG21 is actually just "Did the chair of your sub-sub-committee say there was consensus?" and is typically measured by voting. That's not a consensus, it's a majority.
If you've worked on technical problems with an IETF Working Group you'll know what actual consensus looks like. If you've been around a while you might even have seen abuse of process used to dodge rules and seen demonstrated before you why we need consensus anyway. ISO's procedures are probably adequate for its original goals but they're completely inappropriate for designing a programming language. SC22 should never have existed and is entirely the wrong place to do this work.
You can incrementally refactor existing code to make it more maintainable and easier to implement the things you are working on.
The issue with Netscape (per that article) was that it was a rewrite, not a refactor. I.e. replacing all the existing code with new code. That's why it took a long time to release a new version: the previous code hadn't changed and the new code wasn't functionally equivalent to the existing code, let alone have any new features.
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.
Successor languages usually take a long time. Some of them are made by people who are bad at estimates and will grandly tell you that next year they will have finished the language, but that's just because they actually have no idea. In reality it's typically ballpark ten years.
Most programming languages "go nowhere" in the sense that they never end up used for lots of real world projects - but they can have interesting and useful ideas which inspire future languages.
Google writes a tremendous amount of new code. You can reap a large portion of the benefits by using Rust for new code.
At least as far as public info goes it's still being worked on. The GitHub repo [0] has pretty consistent activity and some recent-ish talks [1], one of which says that they are considering a 0.1 release "early next year".
[delayed]
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.
I understand the issue about the ever-moving target etc., but almost fifteen years later do you really believe C++98 is better than C++11 without move semantics and decent smart pointers? I remember working with Qt5 and C++98 and yes, it was productive, but it was also a mess of intricate object ownership.
I'm critical about some choices made with C++20 and after, like the mess that modules are, and the too-little-too-late ranges library. C++26 is also a joke imho. But on the other hand, working with std::optional and (in C++23) std::expected is so much better than without. The thing is nobody forces you to use every single feature of a new standard, but I would not recommend ignoring very good tools just for the sake of it.
For all of my projects it is good enough. C++11 onwards has a few advantages, but I don't need them. Moving ownership between containers to avoid allocations was possible with the standard library even before C++11, and Qt offered "implicit sharing" which has a similar effect without syntax changes and incompatibilities. Even with my C++11 projects (e.g. https://github.com/rochus-keller/eigen/) I had to take care still in 2024 which feature not to use on MSVC because it didn't work or behaved differently. I never have any ownership issues and I implement large compiler projects with different AST and IR layers. All my projects still compile with https://github.com/rochus-keller/leanqt/ on all platforms. I would never trade a tiny language advantage with a whole world of dependability issues. One day I will revive and refactor GCC 4.7 to get a cross-platform C++98 with parts of 11 compiler just written in C, then latest all of my software is buildable "from first principles".
PS: it's funny I wrote my comment three days (and not an hour) ago.
> Moving ownership between containers to avoid allocations was possible
That's not the biggest upside of move semantics. You can't safely express smart pointers without move semantics. They tried with std::auto_ptr, and it didn't work.
Have a look at Qt implicit sharing. There is/was also a Boost library which could do most of it long before c++11.
> it was also a mess of intricate object ownership
Not much has changed, though, it still is. Just with a lot more bells and whistles around it
>C++26 is also a joke imho.
C++26 will allow billions of lines of pointless serialization boilerplate to finally be deleted, adding the basic reflection functionality that most other languages have had for decades.
[delayed]
Reflection is a joke. De/serializing arbitrary C++ structs is ill-defined. When you need serialization, even lots of it (e.g. silly JSON), I think you're better off writing your own framework where you can be clear about data formats and transformation rules.
Yes, C++26 reflection is nice, but also extremely complex to understand and use well. The rest of C++26 is the usual series of too-little-too-late additions. Meanwhile I’m still waiting for pattern matching to become a thing (a proposal has been discussed for ages)
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.
A big problem is that "consensus" for WG21 is actually just "Did the chair of your sub-sub-committee say there was consensus?" and is typically measured by voting. That's not a consensus, it's a majority.
If you've worked on technical problems with an IETF Working Group you'll know what actual consensus looks like. If you've been around a while you might even have seen abuse of process used to dodge rules and seen demonstrated before you why we need consensus anyway. ISO's procedures are probably adequate for its original goals but they're completely inappropriate for designing a programming language. SC22 should never have existed and is entirely the wrong place to do this work.
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-...
You can incrementally refactor existing code to make it more maintainable and easier to implement the things you are working on.
The issue with Netscape (per that article) was that it was a rewrite, not a refactor. I.e. replacing all the existing code with new code. That's why it took a long time to release a new version: the previous code hadn't changed and the new code wasn't functionally equivalent to the existing code, let alone have any new features.
wait. that's about the green field rewrite of Netscape. not about refactoring where needed.
actually it is very explicitly pushing to refactor and rejuvenate the working field tested code, instead of green field rewriting it.
elsewhere he goes on to what's needed for that, also see the great both entertaining and informative fosdem talks about rejuvenating LibreOffice
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.
When they inverse the priority, there are little reason to keep on using C++.
> 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.
Successor languages usually take a long time. Some of them are made by people who are bad at estimates and will grandly tell you that next year they will have finished the language, but that's just because they actually have no idea. In reality it's typically ballpark ten years.
Most programming languages "go nowhere" in the sense that they never end up used for lots of real world projects - but they can have interesting and useful ideas which inspire future languages.
Google writes a tremendous amount of new code. You can reap a large portion of the benefits by using Rust for new code.
> Carbon seems to have gone nowhere.
At least as far as public info goes it's still being worked on. The GitHub repo [0] has pretty consistent activity and some recent-ish talks [1], one of which says that they are considering a 0.1 release "early next year".
[0]: https://github.com/carbon-language/carbon-lang
[1]: https://github.com/carbon-language/carbon-lang#2026
https://github.com/carbon-language/carbon-lang/pulls?q=is%3A...
an active project indeed!
(2024)
[flagged]