Will Carbon Replace C++?

The last CppNorth 2022 was announced with Chandler Carruth scheduled to give a keynote, where he showed the results of a new scientific experiment. The keynote was titled: Carbon Language: An experimental successor to C++. But why do we need a successor and where did this idea come from?

The last day for the CppCon 2019 conference came with a surprise talk by the same Chandler Carruth and Titus Winters, where they discussed What is C++? I recommend that you listen to this talk as it is very entertaining and informative. I think the most interesting phrase and idea transmitted during the first part of the talk is that “languages are tools and we have to use the right tool for the job.”

At the end of the talk, they made different proposals intended to address some of the common problems that C++ developers face, these proposals were:

• Performance critical software. We are not only talking about speed but also about latency, memory utilization, and battery utilization among other things.
• Software evolution, and language evolution. C++ was written decades ago, language designers also make mistakes and it should be possible to improve and upgrade according to the changes that most languages include these days–there are always, however, people in the community opposed to changing things.
• Simple and easy to read, understand, and write. I think this quote from John Carmack sums it up well: “An enormous virtue of plain old C is that most senior developers are capable of writing their own C compiler, and knowing your tools at that level is valuable! I would need a lot of study time to write a C++ compiler.”
• Practical safety and testing. Safer APIs, cheap security mitigations, and comprehensive testing methodology using Continuous Integrated (CI) unit and integration tests. All untrusted inputs are continuously fuzzed and all tests use checking build mode (sanitizers, asserts).
• Fast and scalable development: modules, essentially.
• Hardware, OSs, Environments. Define what we are committing to support and keep that rolling forward predictably. We’re not going to go out of the way to break your 20-year old platform but we may not go out of our way to keep supporting it either.

Could we improve C++ or use another language?

Carruth gave us information in the last CppNorth 2022. He started by mentioning the proposals for the previous talk and discussing why they weren’t possible to realize for C++. The main problem is the accumulated decades of technical debt, during which the community was prioritizing backward compatibility, which prevents fixing technical debt.

Is there an existing language that could be used in place of C++? Languages using garbage collection are great but we are not going to consider them because they have a performance cost and most C++ developers consider that a trade-off they don’t want to make.

The Rust programming language is a good option because it’s memory safe and it could fit very well as a low-level language replacement, but keeping in mind the following relationships, it doesn’t fit well:

• C –> C++
• JavaScript –> TypeScript
• Objective C –> Swift
• Java –> Kotlin
• C++ –> Rust?

Rust is a language that works perfectly well and it’s very recommendable if you are starting a project right now, but if you need to move a C++ ecosystem to Rust with very deep dependencies, it’s a very hard task. It’s not something that I recommend trying.

What we need is a successor language. A successor language is a language built within an existing ecosystem, without bootstrapping a new one, that provides interoperability, optimizes the learning curve and adoption path, and ideally has tool-assisted migration support. It’s essentially a superset for its ancestor language.

What is the Carbon programming language?

Carruth started his talk with the question C++: What Comes Next? and guided listeners through some questions from the community like why we cannot improve C++, why we cannot use the Go language or another garbage-collected language, or even why we cannot use the Rust language (or another low-level language), before jumping to the need to create a real successor language for C++: Carbon.

Carbon took the proposals for improving C++ and incorporated them into its design goals, but they needed to add a new and critical goal, maybe the most important one: Interoperability with and migration from existing C++ code.

As defined on its website, we can establish the following definition and justification for the creation of the Carbon language:

“Carbon is fundamentally a successor language approach, rather than an attempt to incrementally evolve C++. It is designed around interoperability with C++ as well as large-scale adoption and migration for existing C++ codebases and developers. […] With this approach, we can build on top of C++’s existing ecosystem, and bring along existing investments, codebases, and developer populations.”

Will Go or Dart disappear?

Because this initiative started at Google, where Carruth works as Technical Lead for Google’s Programming Languages and Software Foundations, one might worry that the support for Golang or even Dart could be decreased. Google is a big company, however, and they develop software for different platforms and very different projects. This means that they need different languages for different things.

Go is in use by Google in production for a couple of services (i.e. Google’s download server at dl.google.com) but, as Carruth said, migrating from big C++ projects is very hard and it won’t be done.

Dart is a language on top of JavaScript and other languages with the mission to be the main language for the Flutter project, addressing the creation of cross-platform apps. Because Flutter doesn’t support C++, Carbon is essentially useless in this environment and therefore the Dart language isn’t going to be affected.

How do we develop in this new language?

During Core C++ 2022, Jon Ross-Perkins (a Staff Software Engineer at Google who was working in the Carbon language for 2 years) talked about the syntax and trade-offs for the Carbon language.

The initial part of the talk emphasized the experimental nature of the project at the moment, but I would like to make a few observations about the ecosystem starting with the tooling. Ross-Perking revealed the following tooling goals for the project:

• Compiler. The compilation of the code is very important, of course.
• Formatter. Getting the code formatted correctly.
• Automatic language upgrades. Tidy our code at a higher level than the formatter does.
• IDE and LSP support.
• Refactoring support.
• Package manager.

About writing code, keeping the context where we are developing is important but, do we need to keep that amount of information? Carbon is simplifying the context by giving specific reserved words to make the tooling easier, and code more readable. These reserved words are:

• var – used for declaring variables.
• class – used for defining classes.
• fn – used for defining a function.
• interface – used for defining an interface.
• let – used for declaring a constant.

As an example for each one is shown below:

var radius: Printer(Circle);

class Circle

class Printer(template t:! Type)

fn Draw()

interface Shape

let Pi: f32

I think we can jump into the details of the syntax after this and check out an example of code. But before we start to browse the code, let me say that this language is still experimental and, as with most of the experiments, it could evolve or even disappear. At the moment, the project looks promising and that’s a good signal.

About syntax, this is still not the first release, which means that it could change from what you see here. You can check the design document where the designers and developers are contributing their proposals and changes, if you want to stay up to speed with the latest developments.

import Math;

// Returns the smallest factor of `n` > 1, and
// whether `n` itself is prime.
fn SmallestFactor(n: i32) -> (i32, bool) {
  let limit: i32 = Math.Sqrt(n) as i32;
  var i: i32 = 2;
  while (i <= limit) {
    let remainder: i32 = n % i;
    if (remainder == 0) {
      Carbon.Print("{0} is a factor of {1}", i, n);
      return (i, false);
    }
    if (i == 2) {
      i = 3;
    } else {
      // Skip even numbers once we get past `2`.
      i += 2;
    }
  }
  return (n, true);
}

We are using two different functions here. Looks like the functions inside of the Carbon package are imported by default and we need to import the Math package so we can use it.

We also used two constants (let). The first one (limit) is a constant for the whole function, while the second one (reminder) is a constant in the scope of the while loop, and it’s created and bound to the value in every iteration. The limit constant also declares a type different from the return of the Math.sqrt function, but it’s cast (or converted) using the as i32 suffix.

In the return, we can see the definition of a tuple. We are returning two values instead of only one based on this technique. Languages like Python, Erlang, or Elixir use this type of data. This makes it possible to create a set of values to be handled in different situations.

Roadmap: looking into the future 

Carbon is an experiment at the moment, but you can check the roadmap and see how it is progressing. By comparing the previous entries for the same document we can see that the expected release (stopping the experiment) was slated for 2023, then 2024, and now it has been moved to 2025-2026. However, one thing we can see in the Github Insights is that Carbon is moving fast and it’s not stopping.

Is it going to be a real replacement for C++? We can only guess at the moment but keep in mind other initiatives like Swift or Kotlin. Carbon could be accepted and adopted by most of the big companies that wanted to solve the issues Carbon is addressing, issues addressed by the proposals we enumerated in the beginning of this article.