5 ms·

The Two Factions of C++ (2024)

73 points by signa11 2mo ago

Rochus 2mo ago
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.
- gignico 2mo ago
  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.
  - Rochus 2mo ago
    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/ 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/ 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.
    - maleldil 2mo 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.
      - Rochus 2mo ago
        Have a look at Qt implicit sharing. There is/was also a Boost library which could do most of it long before c++11.
        maleldil 2mo ago
        That's not the same as smart pointers like std::unique_ptr.
        Rochus 2mo ago
        Have a look at boost::movelib::unique_ptr<T> which works well with C++98/03.
  - usrnm 2mo ago
    > 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
    - bluGill 2mo ago
      Much has changed for me since I used smart pointers where possible - which is the vast majority of the time. I am currently telling somebody you can't change a QString to a C string even though the C string probably won't overflow in that use. I have changed.
      - usrnm 2mo ago
        Smart pointers existed long before C++11. std::auto_ptr was a mistake, but it wasn't the only option
        bluGill 2mo ago
        Smart pointers somewhat existed. Without move they were vastly less powerful. (You could have a generic shared pointer without move, but unique pointer has useful properties that you cannot get without move) Non-generic smart pointers - RAII - was very common but that was implemented separately for everything. Having to figure out how to deal with copy was a problem (though many times you disabled it and then passed a reference or a raw pointer to the object - a poor mans move which sometimes was good enough but often was annoying). More importantly, before C++11 every library I worked with had their own incompatible way of managing memory. None of them used smart pointers in the API, it was always raw pointers (or references where possible but often not possible) and their own documented ownership rules. Any single library was simple enough to follow the rules (hint we got it wrong often), but the combination was very complex and sometimes impossible to combine the two different rules. C++11 changed how most people manage memory. You could get the same effect without, but it was both more complex, and nobody agreed on the same rules.
  - logicchains 2mo ago
    >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.
    - gignico 2mo ago
      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)
    - jstimpfle 2mo ago
      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.
      - bluGill 2mo ago
        Reflection is likely useful for a lot of things, but I agree serialization need a better framework.
        jstimpfle 2mo ago
        Yes -- I can see good use for runtimes. For example, compiler can autogenerate good runtime error messages. Thinking about it, debuggers make use of reflection. Debuginfo formats have some kind of reflection built in.
    - tonyedgecombe 2mo ago
      I can't think of a time where using reflection for serialisation hasn't come back to bite me.
    - jcranmer 2mo ago
      I'm not sure C++26 reflection is sufficiently well-baked to actually allow it to be used for serialization boilerplate in codebases. What matters is not what the standard says, but what the compilers implement, and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.
aureate 2mo ago
(2024)
mgaunard 2mo ago
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.
- tialaramex 2mo ago
  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.
  - dundarious 2mo ago
    Look no further than DJB's troubles: https://blog.cr.yp.to/20260814-update.html https://blog.cr.yp.to/20260814-update.html Probably best to go to the index and look at part 1 of the saga.
cherryteastain 2mo ago
> 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.
- aw1621107 2mo ago
  > 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 https://github.com/carbon-language/carbon-lang [1]: https://github.com/carbon-language/carbon-lang#2026 https://github.com/carbon-language/carbon-lang#2026
  - froh 2mo ago
    https://github.com/carbon-language/carbon-lang/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc https://github.com/carbon-language/carbon-lang/pulls?q=is%3A... an active project indeed!
- tialaramex 2mo ago
  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.
- seethishat 2mo ago
  Go is good enough for many tasks. Google wrote that as a replacement for C++ too. I guess Carbon is intended to be more for systems programming? Go had that intent initially, but soon realized that's not a good fit.
pennyforgehq 2mo ago
[flagged]
deleted 2mo ago
[deleted]
aw1621107 2mo ago
Previous HN discussion here (https://news.ycombinator.com/item?id=42231489 https://news.ycombinator.com/item?id=42231489); 2024-11-24, 554 points, 653 comments
- deleted 2mo ago
  [deleted]
feverzsj 2mo ago
Try building google opensource projects. They'll be mostly broken on your own toolchain.
asmnzxklopqw 2mo ago
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.
- j16sdiz 2mo ago
  When they inverse the priority, there are little reason to keep on using C++.
  - fg137 2mo ago
    What seems to be happening today is that outside specific domains like HFT, games, embedded systems or stuff like CUDA where C/C++ is the king, nobody wants to write new code in C/C++ or at least starting new projects in the language, while fervently migrating safety critical code to Rust. Even in those domains there are efforts to do things in Rust, although it's unclear when Rust is going to be an actually serious/viable option. I suspect C++ will become less of a "mainstream" language but only relevant in those specific domains. OS / Services will consider alternatives first.
    - deleted 2mo ago
      [deleted]
tialaramex 2mo ago
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 https://news.ycombinator.com/item?id=42231489
- dang 2mo ago
  Thanks! Macroexpanded: The two factions of C++ - https://news.ycombinator.com/item?id=42231489 https://news.ycombinator.com/item?id=42231489 - Nov 2024 (653 comments)
pif 2mo ago
> 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-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- rhdunn 2mo ago
  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.
- froh 2mo ago
  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
layer8 2mo ago
(2024) Past discussion (653 comments): https://news.ycombinator.com/item?id=42231489 https://news.ycombinator.com/item?id=42231489
deleted 2mo ago
[deleted]
tonyedgecombe 2mo ago
>“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.
- eru 2mo ago
  Haskell has a pretty good story about how to use different dialects in the front end of the language, as long as the backend is still the same. Well, when I say Haskell, I mean ghc. Alas, C++ still mostly does its libraries via conceptual copy-and-paste (#include). So that would need to be fixed, if you wanted to mix-and-match dialects. You could probably keep '#include' syntax, but subtly change its meaning.
- pornel 2mo ago
  > But the major players do seem to be happy to replace their C++ code with Rust. Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched. It's not worth to rewrite C++ into C++++ to get a couple of features that are flawed retrofits backported from modern languages. In the end you still have C++.
  - blub 2mo ago
    The set-up and your reply feel like a Rust sketch. Not touching a codebase only applies to legacy software which is feature complete. Any actively developed software will benefit from incremental improvements. Quality C++ projects continuously improve their code and tooling. It would be very convenient for the rustafarian community if the competition stood still, but that’s not the case. Quite happy to see that golang’s also providing solid opposition.
    - pornel 2mo ago
YuechenLi 2mo ago
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.
- lelanthran 2mo ago
  > There is a good language buried underneath C++ somewhere, it's just that nobody has taken the time to extract it. Carbon?
  - saidinesh5 2mo ago
    Has anyone major used that for any production project though?
  - YuechenLi 2mo ago
    Carbon isn't even a real language, no real language will spent 4 entire years and is still stuck in version 0.0.0-0. It feels more like bad Rust than a proper C++ successor at all. Just to give you a small example? why would a C++ successor language use `fn main()` instead of using C/C++ style `int main()`? And their generics system is even more confusing, are they going to support a new form of generics or are they sticking with templates? And if they are going to add templates, why would they not add pretty much one of the best additions to modern C++ to Carbon, concepts?
vintagedave 2mo ago
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.
abbefaria27 2mo ago
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.
- neutronicus 2mo ago
  The application I work on has an extension API that only requires C++11, but we compile against all the same headers in C++20. Obviously we need ABI compatibility between the two standards for this to work.
- aw1621107 2mo ago
  > Why does it matter if setting -std29 or whatever breaks ABI when -fno-rtti does the same? I think it's the distinction between can and must. Right now you can preserve ABI across compiler versions if you want to (and that is indeed a desirable quality for some users). The pushback is against changes to the standard that would require an ABI break.
randusername 2mo ago
Either the shop will be C++-14 for all time or they will do whatever it takes to use the latest and greatest compilers and language features. I don't see why breaking changes is such a major concern. Unless the aggrieved party is the compiler maintainers, I guess.
HarHarVeryFunny 2mo ago
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.
budman1 2mo ago
You folks are in an HN bubble. C++ is still king of the mountain and it will remain so for decades. The billions of lines of existing C++ are not being re-written in rust (by humans or AI's). 100 thousands of lines are being re-written. C++ is changing, but C++11 is moving across the land. It will be 20 years before the 'new' C++ stuff gets regularly used. Just because it is old, doesn't mean it doesn't have value. Just because it is done a certain way at google, doesn't mean you have to do it that way.
- _hao 2mo ago
  Was about to say the same thing. The amount of training code for LLM's that exists in C++ is probably orders of magnitude more than any other "challenger" languages combined. Love it or hate it C++ is here to stay.
rpnx 2mo ago
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.

73 points by signa11 2mo ago

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.

gignico 2mo ago
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.
- Rochus 2mo ago
  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/ 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/ 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.
  - maleldil 2mo 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.
    - Rochus 2mo ago
      Have a look at Qt implicit sharing. There is/was also a Boost library which could do most of it long before c++11.
      - maleldil 2mo ago
        That's not the same as smart pointers like std::unique_ptr.
        Rochus 2mo ago
        Have a look at boost::movelib::unique_ptr<T> which works well with C++98/03.
- usrnm 2mo ago
  > 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
  - bluGill 2mo ago
    Much has changed for me since I used smart pointers where possible - which is the vast majority of the time. I am currently telling somebody you can't change a QString to a C string even though the C string probably won't overflow in that use. I have changed.
    - usrnm 2mo ago
      Smart pointers existed long before C++11. std::auto_ptr was a mistake, but it wasn't the only option
      - bluGill 2mo ago
        Smart pointers somewhat existed. Without move they were vastly less powerful. (You could have a generic shared pointer without move, but unique pointer has useful properties that you cannot get without move) Non-generic smart pointers - RAII - was very common but that was implemented separately for everything. Having to figure out how to deal with copy was a problem (though many times you disabled it and then passed a reference or a raw pointer to the object - a poor mans move which sometimes was good enough but often was annoying). More importantly, before C++11 every library I worked with had their own incompatible way of managing memory. None of them used smart pointers in the API, it was always raw pointers (or references where possible but often not possible) and their own documented ownership rules. Any single library was simple enough to follow the rules (hint we got it wrong often), but the combination was very complex and sometimes impossible to combine the two different rules. C++11 changed how most people manage memory. You could get the same effect without, but it was both more complex, and nobody agreed on the same rules.
- logicchains 2mo ago
  >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.
  - gignico 2mo ago
    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)
  - jstimpfle 2mo ago
    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.
    - bluGill 2mo ago
      Reflection is likely useful for a lot of things, but I agree serialization need a better framework.
      - jstimpfle 2mo ago
        Yes -- I can see good use for runtimes. For example, compiler can autogenerate good runtime error messages. Thinking about it, debuggers make use of reflection. Debuginfo formats have some kind of reflection built in.
  - tonyedgecombe 2mo ago
    I can't think of a time where using reflection for serialisation hasn't come back to bite me.
  - jcranmer 2mo ago
    I'm not sure C++26 reflection is sufficiently well-baked to actually allow it to be used for serialization boilerplate in codebases. What matters is not what the standard says, but what the compilers implement, and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.

aureate 2mo ago

(2024)

mgaunard 2mo ago

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.

tialaramex 2mo ago
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.
- dundarious 2mo ago
  Look no further than DJB's troubles: https://blog.cr.yp.to/20260814-update.html https://blog.cr.yp.to/20260814-update.html Probably best to go to the index and look at part 1 of the saga.

cherryteastain 2mo ago

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

aw1621107 2mo ago
> 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 https://github.com/carbon-language/carbon-lang [1]: https://github.com/carbon-language/carbon-lang#2026 https://github.com/carbon-language/carbon-lang#2026
- froh 2mo ago
  https://github.com/carbon-language/carbon-lang/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc https://github.com/carbon-language/carbon-lang/pulls?q=is%3A... an active project indeed!
tialaramex 2mo ago
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.
seethishat 2mo ago
Go is good enough for many tasks. Google wrote that as a replacement for C++ too. I guess Carbon is intended to be more for systems programming? Go had that intent initially, but soon realized that's not a good fit.

pennyforgehq 2mo ago

[flagged]

deleted 2mo ago

[deleted]

aw1621107 2mo ago

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

deleted 2mo ago
[deleted]

feverzsj 2mo ago

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

asmnzxklopqw 2mo ago

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.

j16sdiz 2mo ago
When they inverse the priority, there are little reason to keep on using C++.
- fg137 2mo ago
  What seems to be happening today is that outside specific domains like HFT, games, embedded systems or stuff like CUDA where C/C++ is the king, nobody wants to write new code in C/C++ or at least starting new projects in the language, while fervently migrating safety critical code to Rust. Even in those domains there are efforts to do things in Rust, although it's unclear when Rust is going to be an actually serious/viable option. I suspect C++ will become less of a "mainstream" language but only relevant in those specific domains. OS / Services will consider alternatives first.
  - deleted 2mo ago
    [deleted]

tialaramex 2mo ago

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 https://news.ycombinator.com/item?id=42231489

dang 2mo ago
Thanks! Macroexpanded: The two factions of C++ - https://news.ycombinator.com/item?id=42231489 https://news.ycombinator.com/item?id=42231489 - Nov 2024 (653 comments)

pif 2mo ago

> 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-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

rhdunn 2mo ago
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.
froh 2mo ago
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

layer8 2mo ago

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

deleted 2mo ago

[deleted]

tonyedgecombe 2mo ago

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

eru 2mo ago
Haskell has a pretty good story about how to use different dialects in the front end of the language, as long as the backend is still the same. Well, when I say Haskell, I mean ghc. Alas, C++ still mostly does its libraries via conceptual copy-and-paste (#include). So that would need to be fixed, if you wanted to mix-and-match dialects. You could probably keep '#include' syntax, but subtly change its meaning.
pornel 2mo ago
> But the major players do seem to be happy to replace their C++ code with Rust. Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched. It's not worth to rewrite C++ into C++++ to get a couple of features that are flawed retrofits backported from modern languages. In the end you still have C++.
- blub 2mo ago
  The set-up and your reply feel like a Rust sketch. Not touching a codebase only applies to legacy software which is feature complete. Any actively developed software will benefit from incremental improvements. Quality C++ projects continuously improve their code and tooling. It would be very convenient for the rustafarian community if the competition stood still, but that’s not the case. Quite happy to see that golang’s also providing solid opposition.
  - pornel 2mo ago

YuechenLi 2mo ago

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.

lelanthran 2mo ago
> There is a good language buried underneath C++ somewhere, it's just that nobody has taken the time to extract it. Carbon?
- saidinesh5 2mo ago
  Has anyone major used that for any production project though?
- YuechenLi 2mo ago
  Carbon isn't even a real language, no real language will spent 4 entire years and is still stuck in version 0.0.0-0. It feels more like bad Rust than a proper C++ successor at all. Just to give you a small example? why would a C++ successor language use `fn main()` instead of using C/C++ style `int main()`? And their generics system is even more confusing, are they going to support a new form of generics or are they sticking with templates? And if they are going to add templates, why would they not add pretty much one of the best additions to modern C++ to Carbon, concepts?

vintagedave 2mo ago

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.

abbefaria27 2mo ago

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.

neutronicus 2mo ago
The application I work on has an extension API that only requires C++11, but we compile against all the same headers in C++20. Obviously we need ABI compatibility between the two standards for this to work.
aw1621107 2mo ago
> Why does it matter if setting -std29 or whatever breaks ABI when -fno-rtti does the same? I think it's the distinction between can and must. Right now you can preserve ABI across compiler versions if you want to (and that is indeed a desirable quality for some users). The pushback is against changes to the standard that would require an ABI break.

randusername 2mo ago

Either the shop will be C++-14 for all time or they will do whatever it takes to use the latest and greatest compilers and language features. I don't see why breaking changes is such a major concern. Unless the aggrieved party is the compiler maintainers, I guess.

HarHarVeryFunny 2mo ago

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.

budman1 2mo ago

You folks are in an HN bubble. C++ is still king of the mountain and it will remain so for decades. The billions of lines of existing C++ are not being re-written in rust (by humans or AI's). 100 thousands of lines are being re-written. C++ is changing, but C++11 is moving across the land. It will be 20 years before the 'new' C++ stuff gets regularly used. Just because it is old, doesn't mean it doesn't have value. Just because it is done a certain way at google, doesn't mean you have to do it that way.

_hao 2mo ago
Was about to say the same thing. The amount of training code for LLM's that exists in C++ is probably orders of magnitude more than any other "challenger" languages combined. Love it or hate it C++ is here to stay.

rpnx 2mo ago

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.