C++ Should Be C++

Original Article ↗ Hacker News Discussion ↗

C++’s rapid evolution and mounting complexity are polarizing its users: some praise modern standards for making the language more expressive and powerful, while others see them as baroque, hard to learn, and difficult to retrofit onto large legacy codebases. Commenters argue over whether C++ should prioritize being a high-performance systems language, improve ergonomics and safety (potentially in response to emerging “memory-safe” expectations and regulations), or even accept that newer languages like Rust, Zig, or Go may be better suited for many domains. Tooling gaps—especially around modules, dependency management, and build reproducibility—are seen as major practical obstacles regardless of where the language itself goes.

Modern C++ reception

  • Strong split: some find C++20/23 a huge quality-of-life jump (e.g., optional, expected, filesystem, structured bindings, if/switch init, lambdas) and enjoy “modern C++”.
  • Others, especially long-time users, see newer standards as baroque and unpleasant, preferring “C with classes” or a very small subset.
  • Many developers de facto restrict themselves to a project-specific subset, but this is harder in large codebases and as new features (e.g., move semantics) introduce boilerplate or subtle requirements.

Tooling, modules, and dependency management

  • Widely perceived as a major weakness: no standard package manager, and no integrated story for dependencies, testing, logging, etc.
  • Modules are viewed as promising but practically unusable due to uneven compiler and tooling support.
  • vcpkg is criticized for fragile behavior, altered sources, and versioning pinned to commits; Bazel/Buck and Nix/Guix are mentioned as partial answers.
  • Some teams resort to checking toolchains into version control or snapshotting VMs.

Compilation model and performance

  • Compile times are seen as a top pain point, often higher priority than new safety features.
  • Causes discussed: repeated header parsing, template instantiation per translation unit, extra linker work to remove duplicates, and a difficult grammar; disagreement on which factor dominates.
  • Comparisons to Go, Rust, Zig, and C highlight how C/C++’s preprocessing and compilation model age poorly, even with precompiled headers or modules.

Memory safety, regulations, and language direction

  • Disagreement over how much C++ users actually demand memory safety; some say those who care have left, others argue many want it but not via extra paid tools.
  • “Half-measure” safety (opt-in, partial coverage, runtime-costly) is considered of limited benefit.
  • Thread discusses government pressure (NSA/CISA guidance, pending US/EU rules) toward memory-safe languages; no outright bans, but expected procurement and paperwork pressure.
  • Some see the paper as a defensive reaction to Rust, which many view as a credible C++ replacement for systems work.

Standard library, ergonomics, and “zero-cost”

  • Complaints that std lacks high-performance primitives (specialized allocators, lock-free/wait-free structures, IPC, high-performance threading) and isn’t tuned for games/DBs/OS-level workloads.
  • Others argue these belong in external libraries and that no single generic high-performance design fits all workloads.
  • The “zero-cost abstraction” ideal is questioned; hidden control flow (constructors, destructors, copies) and exceptions can carry real cost if misused or poorly optimized.
  • New APIs like std::print are seen as more cumbersome than older idioms (streams) for customization, reinforcing perceptions of poor ergonomics.

Generality, legacy, and alternatives

  • Extended debate over whether “used by millions” proves C++ is a good general-purpose language; some call this a fallacy, others say real-world widespread use across domains is de facto evidence of fitness.
  • Legacy and inertia are repeatedly cited: many people write C++ only because prior code did; huge existing codebases make breaking changes or wholesale rewrites impractical.
  • Some argue C++ should double down on being the fastest systems language; others think its history and complexity make it a poor choice for new programmers compared with Rust or Go.
  • Proposals like Carbon, cppfront, and “C with templates” are mentioned as attempts at fresh starts, but there is skepticism about adoption and the committee’s ability to make radical, breaking changes.