Sane C++ Libraries

Original Article ↗ Hacker News Discussion ↗

A new project, “Sane C++ Libraries,” aims to provide a lean, STL-free alternative ecosystem for C++ with faster compile times, simpler abstractions, and practical utilities like async I/O, JSON, and reflection. Commenters are split: some welcome the focus on minimalism, explicit error handling, and avoiding exceptions, RTTI, and smart pointers, while others argue that shunning the standard library worsens fragmentation and sacrifices mature, well-optimized components. The exchange highlights long‑running tensions in C++ between performance, simplicity, portability, and reliance on the standard library versus custom or third‑party foundations.

Overall goals and positioning

  • Library aims to model an “alternative C++ world” more like Python/Node/Zig/C: practical functionality, async I/O, platform abstraction, smaller binaries, no exceptions/RTTI/stdlib.
  • Author emphasizes fun, simplicity, and focusing on the “95% of use cases” rather than every edge case.
  • Some see it as a middle ground between unsafe C and bloated libstdc++; others view “no stdlib / no exceptions / custom atomics” as inherently not “sane.”

Stdlib avoidance & ecosystem fragmentation

  • Several commenters object that ignoring the STL guarantees more fragmentation and poor interop; they already struggle with every C++ library defining its own String/Vector types.
  • Others argue STL has design/compatibility baggage (e.g., vector<bool>, standard maps, std::regex, heavy templates, slow debug builds) and that many serious projects already roll their own core library.
  • Comparison to Abseil: Abseil complements the STL, while this project intentionally replaces most of it.

Containers, algorithms, and data structures

  • Current container set is seen as incomplete; lack of standard-like sets, queues, deques, and hash maps is a blocker for some.
  • Some users rely heavily on stack/deque; author is skeptical of deque and prefers vector-based solutions and arena-style containers.
  • “Algorithms” library currently shows bubbleSort first; this led to criticism, with the author clarifying it’s a placeholder and will expand over time.

Memory management, smart pointers, and exceptions

  • Project deliberately omits SharedPtr/UniquePtr, based on a principle against many tiny heap objects and unclear/shared ownership.
  • Some strongly disagree, wanting smart pointers for all heap objects and seeing them as zero- or low-overhead safety tools.
  • Others describe patterns using vectors/arenas, handles, and clear ownership groups instead of smart pointers.
  • Larger debate: many commenters defend exception-free C++ (often with ErrorOr-style types) as common and practical; others insist C++ “cannot be exception-free” in any meaningful sense, arguing that all error handling is still “exceptions in disguise.”
  • Concerns about C++ exceptions include non-zero overhead, RTTI, hidden control flow, unclear throwing behavior from function signatures, and encouraging “happy path only” code.

Atomics and low-level concerns

  • Custom atomics are questioned given that std::atomic is deeply tied to the C++ memory model.
  • The no-stdlib rule is the immediate reason; author hints at a future opt-in flag to use standard headers where available.

Build system and macros

  • Describing builds in C++ is criticized as not “sane”; pro-declarative arguments cite scalability and simplicity.
  • Author counters that popular “declarative” tools (e.g., CMake) are effectively imperative DSLs anyway.
  • Some dislike the project’s macro usage as un-“sane”; author notes most macros are platform switches, with optional macros in reflection.