At the C++ North event under way in Toronto this week, Google software engineer Chandler Carruth presented the Carbon Language, described as an “experimental successor to C++”, evoking high interest in the C++ community.

“We understand the community interest in this keynote. We will post the recording on an accelerated schedule,” said the conference organizers on Twitter. Carruth is technical lead for Google’s core programming languages and language evolution, represents Google on the C++ Standards Committee, and is a contributor to LLVM and Clang.

The Carbon developers explain that while C++ is the “dominant language for performance-critical software,” its legacy and technical debt means that “incrementally improving C++ is extremely difficult.”

One solution is to migrate to other languages such as Rust, Kotlin, Swift or Go, but these languages are hard to migrate to, and in some cases have performance overhead. Carbon is a new language that aims to match the performance of C++ and maintain “seamless bidirectional interoperability,” as well as a gentle learning curve for C++ developers.

The team also promise “some level of source to source translation” for C++ code. The project has parallels with TypeScript for JavaScript developers, or Kotlin for Java developers, though the comparison is not an exact one. Carbon is designed to be interoperable with C++ code and to make migration easy. The Carbon toolchain will support compiling C++ code.

Why is C++ hard to improve? C++ itself started as a fork of C, and the C language is 50 years old, so it is not surprising that there is a lot of legacy. According to the Carbon team, the C++ designers have added rather than replaced language features over time, creating complex feature interactions. Preserving binary compatibility is another legacy problem. In addition, the C++ committee and evolution process is “oriented around standardization rather than design”, is slow and sometimes fails to make decisions.

Carbon is an effort to side-step these problems with a new approach based on open source principles. “We will even try to close a huge gap in the C++ ecosystem with a built-in package manager,” state the documents. The current roadmap aims to complete version 0.1 of the language this year, 0.2 in 2023, and version 1.0 in 2024 or 2025.

The Carbon language will look familiar to C++ and C developers, though there are also many differences. Functions are declared with the fn keyword and variables with var. There are also strongly typed tuples. Type inference is supported with the auto keyword. Pointers are supported but not pointer arithmetic; the only pointer operations are address-of and dereferencing. Classes support single inheritance but not multiple inheritance.

Memory safety is an important consideration but is not the initial goal. “The difference between Rust’s approach and Carbon’s is that Rust starts with safety and Carbon starts with migration,” say the docs. The approach is to simplify the language in order to “create space for safety features,” and then to “re-engineer foundations to model and enforce safety.”

The project is licensed under Apache 2 with LLVM exceptions. According to the team, “we are planning to create an open source foundation and transfer all Carbon-related rights to it; our goal is for the foundation setup to be similar to other open source projects such as LLVM or Kubernetes.” However the project currently requires contributors to agree to Google’s CLA (contributor license agreement), which may be a problem for some. Google is also funding the Carbon infrastructure.

An FAQ addresses common questions, like why not use Rust? “If you want to use Rust, and it is technically and economically viable for your project, you should use Rust,” is the answer.

That Rust question though is at the heart of whether Carbon will succeed. “Rust (from my biased point of view) is currently on its way to become the standard low-level language, so I’m not too confident that Rust-but-with-OO is enough of a selling point,” said one developer on Hacker News. Another said though, “There are probably more C++ projects started every day than Rust projects. So anything that makes it possible to move beyond C++ while being 100% interoperable is good news.”