The Two Factions of C++: Modern Tooling vs. Legacy Lock-In

The Two Factions of C++: Modern Tooling vs. Legacy Lock-In

C++ is splitting into two camps: those with modern tooling who can build from versioned source, and those stuck with legacy code that can't be migrated. The C++ committee's commitment to backwards compatibility, exemplified by the recent reaffirmation of design principles, favors the latter, frustrating the former. This rift explains the struggles of profiles, modules, and the exodus of big tech to Rust.

There’s a massive, growing rift between those two factions (good tooling, can effortlessly build from source vs. poor tooling, can’t build from source), and I honestly don’t see it closing anytime soon.
  1. tonyedgecombe

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

  2. tialaramex

    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

  3. vintagedave

    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.

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

  5. feverzsj

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

More from this day

2026-08-19