Circle C++ with memory safety

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.