Carbon Language: An experimental successor to C++

Project status and roadmap

• Official roadmap targets: safety design “TBD end 2025” and a 0.1 release “TBD end 2026”; 1.0 vaguely “towards end of 2026”.
• Current compiler is experimental; available via Compiler Explorer, but basic things like strings and I/O are incomplete and require workarounds.
• Several commenters feel the project is moving at roughly Rust’s early pace but without Rust’s strong community forum presence.

Core goals and design space

• Primary goal: incremental migration of very large C++ codebases (e.g., Chrome) to a “saner” language while coexisting in one build and toolchain.
• Emphasis is on seamless C++ interop, source‑to‑source translation tools, and being usable inside big existing C++ shops, with Google as the main initial customer.
• Team members stress they study many languages (Rust, Swift, Go, Kotlin, etc.), though some worry it’s still too C++‑community‑centric.

Relationship to C++ and ABI debates

• Much discussion centers on C++’s committee culture: unwillingness to break ABI, reliance on UB, and failure of “Safe C++” and profile proposals.
• One view: Carbon exists because large players couldn’t get WG21 to move on ABI and safety; C++ is “stuck” serving legacy code.
• Carbon calls itself “performance‑first”: default ABI instability with a not‑yet‑fleshed‑out opt‑in stable ABI, explicitly not aiming to replace the C ABI as lingua franca.

Safety model and trade‑offs

• Carbon plans a “safe subset” only after 0.1; some argue that deferring safety means it may never be properly baked in.
• Others provide a nuanced view: “getting safety right” depends on which memory‑safety properties are worth enforcing given interop and performance goals; Java, Rust, Zig, Swift are cited as different points on this spectrum.
• There is debate over how much UB elimination is necessary vs. practical for C++ interop.

Syntax and ergonomics

• Lengthy bikeshedding over fn vs func/fun/proc, whether a function keyword is needed at all, and how parsers and debuggers benefit from explicit keywords.
• Mixed reactions to using [] vs () for generics and type arguments; some find the rules (deduced vs explicit) coherent, others see inconsistency.
• Some C++ developers say Carbon’s syntax diverges enough (e.g., fn, var, bracketed generics) that it may alienate exactly the audience it targets.

Alternatives and necessity of Carbon

• Commenters point out that D, Zig, Nim, Swift, Kotlin, Hack, and even Rust have various C/C++ interop and incremental‑migration stories, though none fully match Carbon’s stated “drop‑in C++ replacement” ambition.
• Ideas like Clang‑based C++‑to‑Rust/D transpilers are floated; others argue such translation would yield unmaintainable output or fail on C++ features Rust can’t express safely.
• One camp believes disciplined “safe C++ subsets” plus tooling are enough; another argues only a new language that makes unsafe patterns unexpressible can hold the line over decades.

Trust, governance, and corporate influence

• Some praise the vision but worry about Google’s history of abandoning projects and whether Carbon would be maintainable by a wider community.
• Others suggest waiting to see serious internal adoption (e.g., in Chrome) before investing.
• A minority is harshly critical, questioning design quality, pace, and motives, framing Carbon as a corporate reaction to losing influence over C++ rather than a purely technical initiative.