Carbon

See our announcement video from CppNorth. Note that Carbon is not ready for use. C++ remains the dominant programming language for performance-critical software, with massive and growing codebases and investments. However, it is struggling to improve and meet developers' needs, as outlined above, in no small part due to accumulating decades of technical debt. Incrementally improving C++ is extremely difficult, both due to the technical debt itself and challenges with its evolution process. The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax. Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should . Unfortunately, the designs of these languages present significant barriers to adoption and migration from C++. These barriers range from changes in the idiomatic design of software to performance overhead. With this approach, we can build on top of C++'s existing ecosystem, and bring along existing investments, codebases, and developer populations. There are a few languages that have followed this model for other ecosystems, and Carbon aims to fill an analogous role for C++: JavaScript → TypeScript Java → Kotlin C++ → Carbon While many languages share subsets of these goals, what distinguishes Carbon is their combination. Our detailed goals document fleshes out these ideas and provides a deeper view into our goals for the Carbon project and language. Carbon Language is currently an experimental project. We are hard at work on a toolchain implementation with compiler and linker. You can try out the current state at compiler-explorer.com. We want to better understand whether we can build a language that meets our successor language criteria, and whether the resulting language can gather a critical mass of interest within the larger C++ industry and community. If you're interested in contributing, we're currently focused on developing the Carbon toolchain until it can support Carbon ↔ C++ interop. Beyond that, we plan to continue developing the design and toolchain until we can ship the 0.1 language and support evaluating Carbon in more detail. The Carbon code here is hypothetical and meant to show the look and feel of the language. You can call Carbon from C++ without overhead and the other way around. This means you migrate a single C++ library to Carbon within an application, or write new Carbon on top of your existing C++ investment. For example: Beyond interoperability between Carbon and C++, we're also planning to support migration tools that will mechanically translate idiomatic C++ code into Carbon code to help you switch an existing C++ codebase to Carbon. Carbon provides a modern generics system with checked definitions, while still supporting opt-in templates for seamless C++ interop . Checked generics provide several advantages compared to C++ templates: Generic definitions are fully type-checked , removing the need to instantiate to check for errors and giving greater confidence in code. Avoids the compile-time cost of re-checking the definition for every instantiation. When using a definition-checked generic, usage error messages are clearer, directly showing which requirements are not met. Enables automatic, opt-in type erasure and dynamic dispatch without a separate implementation. This can reduce the binary size and enables constructs like heterogeneous containers. Strong, checked interfaces mean fewer accidental dependencies on implementation details and a clearer contract for consumers. Without sacrificing these advantages, Carbon generics support specialization , ensuring it can fully address performance-critical use cases of C++ templates. For more details about Carbon's generics, see their design. Safet