Circle C++ with memory safety

Original Article ↗ Hacker News Discussion ↗

A new proprietary compiler called Circle aims to make C++ memory-safe by adding Rust-like borrow checking and a safer standard library, sparking debate over whether this can truly fix long‑standing issues in the language. Commenters contrast Circle with other “C++ successor” efforts such as Carbon and cpp2, and with alternatives like Rust, Ada, Zig, and tooling-based approaches (sanitizers, Fil‑C), weighing trade‑offs between safety, performance, and compatibility with massive existing C++ codebases. Many see the idea of a memory-safe C++ superset as technically impressive and potentially valuable for high-assurance domains, but question adoption prospects given Circle’s closed-source status and the industry trend toward Rust for new systems work.

Circle’s Approach to C++ Memory Safety

  • Circle is presented as a C++-compatible language adding Rust-style ownership, borrowing, lifetimes, and exhaustive pattern matching to enforce memory safety.
  • It aims to be a “superset of C++” so existing code can compile, while new code can opt into stricter, borrow-checked semantics.
  • Some see it as the most concrete “TypeScript-for-C++” path, with an existing compiler, versus other successor experiments.

Comparisons to Rust, Carbon, Ada, Zig, Others

  • Rust is repeatedly cited as the current benchmark for systems-level memory safety, with both technology and culture that push safer APIs, though it still allows unsafe and logical errors.
  • Carbon is discussed as another C++ successor; its current story on data races and whether its safety model will match Rust’s is seen as unsettled/compromised.
  • Ada/SPARK are mentioned as earlier safe systems languages; opinions differ on how fully they achieve Rust-like guarantees and on their relevance today.
  • Zig is praised as a more “pragmatic systems” language that accepts explicit unsafety where needed.

Undefined Behavior, Data Races, and Analysis Limits

  • There is extended debate around UB: what compilers are allowed to reject, Rice’s theorem/halting problem limits, and how much UB a C++-successor with C++ interop must inherit.
  • Data races are highlighted as a key part of “real” memory safety; some argue you can’t credibly claim safety without preventing them, others argue you can still meet some security goals.

Adoption, Licensing, and Ecosystem Concerns

  • Circle is currently proprietary; many see that as a deal-breaker for wide adoption, others argue large enterprises will pay if it solves a big risk for huge C++ codebases.
  • There’s skepticism about any non-open successor language gaining traction, and about projects that aren’t clearly used in production.
  • Some argue that migrating to Rust is more realistic long-term, even for big shops; others say rewrites of mission-critical C++ are too risky.

Broader Safety Debate

  • Several comments stress that memory safety bugs dominate high-severity vulnerabilities in large C/C++ codebases, though some dispute how broadly these stats generalize.
  • Others argue memory safety is only one bug class; logic and performance bugs are more common in many domains, and over-focusing on memory safety may distract from overall correctness.
  • Style issues (e.g., missing braces) are cited as low-hanging safety wins; others counter that tooling and warnings already mitigate such risks.