Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.
    by Rochus
  • Try building google opensource projects. They'll be mostly broken on your own toolchain.
    by feverzsj
  • > 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.

    by cherryteastain
  • 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.

    by mgaunard
  • 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.

    by vintagedave
  • 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.

    by abbefaria27
  • 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

    by tialaramex
  • >“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.

    by tonyedgecombe

Explore Birbla archives