A few weeks ago at CppNorth, Google engineer Chandler Carruth unveiled Carbon — an experimental programming language positioned as a “successor to C++.” The announcement generated enormous buzz, GitHub stars piled up overnight, and the inevitable hot takes followed. Now that the dust has settled a bit, I think it’s worth looking at this with clear eyes.
The pitch is straightforward: C++ has decades of accumulated complexity, backward compatibility constraints make modernization painful, and the committee process moves slowly. Carbon aims to provide a modern language that can interoperate with existing C++ code, similar to how Kotlin relates to Java or Swift relates to Objective-C. Migrate incrementally, don’t rewrite from scratch.
The Interoperability Argument#
The strongest part of Carbon’s value proposition is C++ interoperability. There are billions of lines of C++ in production — game engines, operating systems, embedded systems, financial trading platforms, browsers. Rewriting that code in Rust or any other language is a multi-year, multi-team effort that most organizations can’t justify.
Carbon proposes bidirectional interop: call Carbon from C++ and C++ from Carbon, with automatic bridging of types and functions. If they can deliver on this promise, it addresses a genuine gap. Rust’s C++ interop story, while improving through projects like cxx, still requires significant manual bridging work and doesn’t support calling Rust from C++ as seamlessly as the other direction.
The question is whether this interop can actually work at the level of fidelity needed. C++ has templates, multiple inheritance, implicit conversions, overload resolution rules that fill hundreds of pages in the standard — faithfully bridging all of this is a herculean task. The Carbon team acknowledges this and is focusing on practical interop patterns rather than trying to support every dark corner of C++.
How Carbon Compares to Rust#
This is the comparison everyone’s making, and it’s worth addressing directly. Rust and Carbon occupy similar spaces — systems programming languages designed to be safer than C++ — but they make fundamentally different trade-offs.
Rust chose to break from C/C++ compatibility entirely and build a new ecosystem from scratch. The result is a language with powerful safety guarantees (the borrow checker, ownership model) but a higher migration cost. You can’t incrementally port a C++ codebase to Rust; you effectively need to rewrite modules and maintain FFI boundaries.
Carbon is betting that interoperability matters more than maximum safety innovation. It provides generics instead of templates, pattern matching, a cleaner syntax, and memory safety improvements — but it doesn’t go as far as Rust’s ownership model. The reasoning is that asking C++ developers to adopt a fundamentally different mental model is too high a barrier.
From what I’ve seen of the early design documents, Carbon’s approach to generics is particularly interesting. Instead of C++ templates (which are essentially duck-typed compile-time macros), Carbon uses checked generics similar to Rust traits or Haskell typeclasses. This alone would eliminate a massive category of inscrutable template error messages.
The Elephant in the Room: It’s From Google#
Let’s talk about the Google factor. The company has a well-documented history of abandoning projects — the “Google Graveyard” is a running joke in the industry. For a programming language that’s asking for long-term investment from developers and organizations, this track record matters.
Carbon is currently marked as experimental, with no production-ready compiler. The team is transparent about this being a 5-10 year journey, and they’re building it as an open-source community project rather than a purely internal Google effort. The governance model they’ve proposed attempts to prevent single-company control.
But we’ve seen this before. Dart was supposed to replace JavaScript in the browser — it found its niche with Flutter but never achieved its original ambition. Go succeeded spectacularly, but Go was also production-ready when it launched and had clear, immediate use cases. Carbon is asking people to invest in a vision that won’t materialize for years.
Does the C++ Ecosystem Actually Want This?#
There’s a deeper question here: does the C++ community want a successor language, or do they want C++ to evolve faster? The C++20 and C++23 standards have brought significant modernization — concepts, coroutines, modules, ranges. C++26 is shaping up to include reflection and pattern matching.
Every time someone proposes replacing C++, a significant portion of the C++ community pushes back. They’ve invested decades in mastering the language’s complexity, and they see incremental standards evolution as the path forward. Carbon needs to convince these developers that a clean break (even with interop) is worth the transition cost.
The C++ committee process is slow, yes, but it’s slow for reasons — backward compatibility, portability across dozens of platforms and compilers, consensus among hundreds of stakeholders. Carbon will eventually face similar pressures if it achieves adoption at scale.
My Take#
I’m cautiously interested but not holding my breath. The interoperability story, if they can deliver it, addresses a genuine pain point that Rust doesn’t fully solve. But the project is so early that evaluating it seriously feels premature — there isn’t even a self-hosting compiler yet.
My pragmatic advice: if you’re starting a new systems programming project today, Rust is the proven choice with a mature ecosystem, excellent tooling, and a growing community. If you’re maintaining a large C++ codebase and dreaming about incremental modernization, keep an eye on Carbon, but don’t plan around it yet.
The systems programming space is healthier than it’s been in decades. Whether Carbon succeeds or not, the pressure it puts on C++ to modernize faster is a net positive. Competition drives improvement, and C++ developers deserve better ergonomics regardless of which language delivers them.