Google Launches Carbon, an Experimental Replacement for C++
Frustrated by the slow evolution of the C++, Google engineers have launched a new “experimental” open source programming language, called Carbon, as a possible successor to the venerable but aging C++.
Long the language of choice for building performance-critical applications, C++ is plagued with a number of issues that hamper modern developers, Carruth explained on a GitHub page. It has accumulated decades of technical debt, bringing with it many of the outdated practices that were part of the language’s predecessor, C. The keepers of C++ prioritize backward compatibility, in order to continue to support widely-used projects such as Linux and its package management ecosystem, Carruth charged.
The language’s evolution is also stymied by a bureaucratic committee process, oriented around standardization rather than design. Which can make it difficult to add new features. C++ has largely a sequestered development process, in which a select committee makes the important decisions, in a waterfall process that can take years.
“The committee structure is designed to ensure representation of nations and companies, rather than building an inclusive and welcoming team and community of experts and people actively contributing to the language,” Carruth wrote. “Access to the committee and standard is restricted and expensive, attendance is necessary to have a voice, and decisions are made by live votes of those present.”
While Carbon began as a Google internal project, the development team ultimately wants to reduce contributions from Google, or any other single company, to less than 50% by the end of the year. They ultimately want to hand the project off to an independent software foundation, where its development will be led by volunteers.
— Conor Hoekstra (@code_report) July 19, 2022
What’s in the Box?
The design wants to release a core working version (“0.1”) by the end of the year. Carbon will be built on a foundation on modern programming principles, including a generics system, that would remove the need to check and recheck the code for each instantiation.
Another much needed feature lacking in C++ is memory safety. Memory access bugs are one of the largest culprits of security exploits. Carbon designers will look for ways to better track uninitialized states, design APIs and idioms that support dynamic bounds checks, and build a comprehensive default debug build mode. Over time, the designers plan to build a safe Carbon subset.
According to the documentation, the language will support:
- Performance-critical software
- Software and language evolution
- Code that is easy to read, understand, and write
- Practical safety and testing mechanisms
- Fast and scalable development
- Modern OS platforms, hardware architectures, and environments
- Interoperability with and migration from existing C++ code.
The development team will also set out to create a built-in package manager, something that C++ sorely lacks.
Here is some C++ code translated into Carbon. First, the C++ code:
Here is the same function written in Carbon:
The development team plans to write translation tools to migrate C++ code into Carbon code.
Why Not Rust Then?
Rust was another recent language built specifically to address the needs of memory-safe performance applications. So why not just use Rust then? In his presentation at CPP North, Carruth advised those using Rust to continue to use it. Carbon is for those developers who already have large codebases in C++, which are difficult to convert into Rust. Carbon is specifically what Carruth called a “successor language,” which is built atop of an already existing ecosystem, C++ in this case.
“It is designed around interoperability with C++ as well as large-scale adoption and migration for existing C++ codebases and developers,” the documentation explains. This means the language should be as performant as C++, it should provide seamlessly, and offer bidirectional interoperability with C++.
Google’s #Carbon programming language reminds me of the approach Apple took going from #ObjC to #Swift. In my experience that was a really good approach. It made porting Objective-C code to Swift a lot easier, since you never had to do a full port.https://t.co/dQK5wV0J0B
— Erik Engheim (@erikengheim) July 20, 2022