The two factions of C++

Original Article ↗ Hacker News Discussion ↗

C++ is increasingly split between organizations treating their codebases as long‑term assets with modern tooling and testing, and legacy environments that prioritize ABI stability and minimal change over safety and evolution. Commenters debate whether the language should adopt Rust‑style memory safety and stronger tooling (including package management and editions) or remain a “better C” with zero‑overhead abstractions and strict backward compatibility, even at the cost of security and ergonomics. Many see large players moving new development to Rust or other languages, leaving C++ to persist mainly in massive, hard‑to‑rewrite legacy systems.

Package Management & Tooling Fragmentation

  • Strong frustration with C++’s lack of standard tooling: compilers, build systems, and package managers are all fragmented and hard to combine, especially across platforms.
  • Disagreement on where package management should live:
    • Some argue it “belongs to the OS” to avoid language silos and trust new central authorities.
    • Others say OS package managers solve a different problem (shipping apps, not per-project dependency graphs), can’t handle multiple versions, and are tied to a single OS/distro.
    • Several want a language‑agnostic package layer that can feed both OS managers and build tools; others fear an impossible “one standard to rule them all.”
  • Tools mentioned: CMake, vcpkg, conan, Bazel, Nix/Guix, CPM, xrepo, Docker. Containers are seen by some as a pragmatic fix and by others as an unacceptable workaround.

Editions, Profiles, and “Safe C++”

  • Rust’s Editions model is widely admired as a way to evolve syntax without breaking existing code; people debate whether something similar is viable for C++.
  • Obstacles cited: textual includes, ODR and ABI issues, multiple stdlib ABIs, and the lack of a clear “crate” boundary equivalent.
  • Two main safety directions discussed:
    • “Profiles” that add static checks without changing syntax or requiring annotations, aimed at existing code and minimal disruption.
    • A “Safe C++”–style approach that adopts Rust-like lifetimes and annotations, opt‑in per file, giving stronger guarantees but effectively creating a “new C++”.
  • Profiles are derided by some as “vaporware” whose promises (“full safety without annotations”) are unrealistic; others see them as a practical, incremental safety path for large legacy bases.

Memory Safety vs Productivity and Culture

  • Deep split over whether C++ should move toward Rust-like safety:
    • One camp wants stronger static checking, seeing widespread memory corruption and UB as unacceptable even outside safety‑critical domains.
    • Another camp values existing processes, zero‑overhead abstractions, and the ability to write “unsafe but fast” code; they recommend using Rust instead of changing C++.
  • Some argue safety isn’t free: lifetime systems can impose cognitive and syntactic costs that are not justified for all business software.
  • Others counter that humans are bad at following complex rules reliably; anything the compiler can check, it should.

Legacy Code, ABI, and Language Evolution

  • Stable stdlib ABI is seen by some as necessary for distros, proprietary binaries, and huge codebases that can’t be rebuilt easily.
  • Others say ABI‑freezing of std types (e.g., string, containers) has effectively sacrificed performance and evolution of core facilities; they blame this for making C++ less attractive vs newer languages.
  • There is pessimism that large organizations will ever accept breaking changes that require touching even “1% of lines” in million‑line codebases; others provide anecdotes of successful large-scale ports but acknowledge the cost.

Big Tech, Monorepos, and Committee Politics

  • The article’s framing of two “factions” resonates with many: modern, tooling‑heavy organizations (monorepos, auto‑refactoring, strict testing) vs legacy shops that resist change and lack tests.
  • Some note a visible slowdown in big vendors’ C++ standard adoption and investments, as they explore Rust, Swift, Carbon, etc.
  • There is concern that committee decisions are increasingly constrained by legacy users and ABI promises, making ambitious safety or tooling‑oriented changes hard to land.