carbon-lang
Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
Carbon: a language that wants to succeed C++ rather than fix it
Carbon is an experimental successor to C++. The README argues that C++ carries too much technical debt to keep patching, so Carbon starts over while staying able to talk to existing C++ code.
The basic promise
An experimental language meant to succeed C++, not to keep evolving C++. Performance should match C++ using LLVM, with low level access to bits and addresses. Existing C++ code, from inheritance to templates, should interoperate. Builds should be fast and scalable, working with the build systems teams already use.
Why start over
The README makes its argument plainly: C++ still dominates performance critical software, but it is hard to improve because decades of technical debt have accumulated. Incremental change is slow and painful. The bet is to build on solid foundations rather than inherit the legacy of C or C++ directly, starting with things like a modern generics system and consistent, simple syntax.
What a successor needs
The project lists its own requirements: performance matching C++, bidirectional interoperability so a library anywhere in an existing C++ stack can adopt Carbon without porting everything, a gentle learning curve for C++ developers, comparable expressivity, and scalable migration with some source to source translation. Languages like Go, Swift, Kotlin, and Rust are good, the README says, but each one carries barriers for C++ teams, from idiomatic changes to performance overhead.
Where it stands today
Carbon is early and experimental. A toolchain with compiler and linker is under active development, and people can try the current state at compiler-explorer.com. Nightly releases exist for limited platforms only. A prototype explorer interpreter from an older design has been archived. The project is explicit that the 0.1 milestone is where things start to get solid.
Safety plans
Memory safety is treated as a central problem. The plan runs in two stages: automated migration of existing C++ into a Carbon dialect built for interop, then incremental refactoring toward memory safe designs, patterns, and APIs. Early wins on the list include better tracking of uninitialized states, dynamic bounds checking in fundamental APIs, and moving away from undefined behavior where possible.
Editorial conclusion
Carbon is candid about being unfinished, which works in its favor. The interesting part is not what compiles today, it is the design decisions about interop and migration being settled out in the open.
Community notes