Our CI/CD Learning Tool is out. Have a look! Upvote now on Product Hunt -->

    28 Feb 2023 · Software Engineering

    Will Carbon Replace C++?

    9 min read

    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.

    30 thoughts on “Will Carbon Replace C++?

    1. The ‘vision’ for Carbon is unclear; in some places it’s claimed to target replacing C++ yet, in others, it claims to be a means of experimenting with features that C++’s standardisation constraints cause hassle and delays with. In some places it claims to be trying to overcome the technical debt of C++, yet the plans appear to be to retain many of the (IMO) dodgy aspects of C++’ because they’re what people are used to ‘.

      As far as I can tell, it might gain a similar market share to other Google languages, but it won’t replace C++; it would need far more clarity in planning of design, implementation and standardisation for that.

      1. I think so, I mean, at the moment Carbon is an experiment from Google, they try to scratch their own itch because they have thousands of C++ files for the Google Search Engine and they want to “modernize” the development without rewriting everything in only one big step.

    2. Rust offers some interesting technological benefits.

      Unfortunately, Rust is also considered completely unusable by many individuals and businesses due to its totalitarian community.

      This totalitarianism includes things like Rust’s contradictory and arbitrary “Code of Conduct”, the “Moderation Team”, witch hunts, and censorship.

      Sensible people and organizations don’t want to risk harassment merely for accidentally running afoul of the Rust community in some minor and obscure way.

      This is especially true when “progressives” often deem what was perfectly acceptable yesterday to suddenly be horrific and unacceptable today.

      How will the Carbon community avoid being plagued by problems like those?

      1. I haven’t heard of much political drama in the Rust community and the language decisions felt very pragmatic (eg. async, the ? operator).
        That’s one of the reasons I’m happy to leave JavaScript behind.

        There is definitely a certain type of bias in the Rust community (but not any different than in tech in general) but I’ve never encountered something like you were describing.

        The only drama I can remember was the usual bashing of OSS volunteers in the actix saga. Again, that happens a bit everywhere (and it’s one of the reasons I don’t even bother publishing most of my code).

        Would you mind sharing some examples?

        1. I agree that I would want to see practical examples where Rust community has been problematic.

          I still feel like a beginner when it comes to Rust (I can write multi-threaded programs with shared memory structures without using any unsafe blocks but I don’t feel efficient at all because of lack of skills), but every interaction I’ve had with the community has been positive.

          The community may be a bit anti-rasism / anti-exclusion oriented, do if you feel that your freedom must include insulting other people without limits, then I can see how the community is not welcoming to your attitude.

          However, if you have some specific examples of problematic behavior, I’d be interested to learn more about those cases.

    3. So I was excited for this project and I realize it’s very early and a little unfair to critique it. But I would say that looking at the provisional doc that early Carbon is not to my taste. A couple points:

      – needing to include “let v: auto” to enable type inference for local variables seems needlessly different from every other language with this syntax
      – auto return type for function signatures means you’ll need to type the body of the function to get the signature, bleh that’s bad for parallelism
      – the “impl as” syntax for implementing an interface seems clunky when there’s a Java syntax for interfaces that everyone knows
      – forward declarations seem like a strange choice for a modern language? I thought this was a relic of single pass compilers?
      – ideally a C++ interop language would use the STL with some extensions? Or Abseil?

      Ultimately this is just a matter of taste, but I really would like a C++ successor language to simplify the language and make it easy to express common patterns and I don’t see that with Carbon yet. If anything, it seems like it’s going to be more complicated (need to learn all the C++ rules and the Carbon rules and how they interact)

      Additionally, it feels a little bit like the Go generics story where the team was supposedly too focused on C++/Java generics to accept that there were other approaches out there. It’s just not to my taste. But of course, it’s still early and taste isn’t everything anyways. Here’s hoping to the project improving!

      1. I agree with you, the syntax is very weird and it recalled me to some parts of JavaScript. I think they are still thinking about it and the current syntax maybe it’s not the definitive one. However, they are approaching this from the point of view to make the code easier for the compiler, removing ambiguous code, and being more explicit. We will see how is going the experiment 🙂

    4. I like the idea behind carbon and I think this is the best way to improve c++ ecosystem. C++ itself is a self complicated language due to C compatibility and complex features that don’t gel with C. However this is only 50% of the problem. The other 50% is due to broken dependency management using static and dynamic libraries and static linking of header files. This is a pure nightmare. Suppose I build a library in carbon, how to use that in a c++ code base? And this needs to work via a build tools like bazel and makefiles. As long as bazel can manage the dependencies seemlessly behind the scene, it should be pluggable inside an existing makefile? If this part is sorted out, Carbon will not only replace c++, but, it will become a mainstream language. I would like to know how this problem is addressed.

      1. C# is a language with a virtual machine and garbage collection. It cannot easily changed to systems programming language even though deterministic allocation and destruction would allow nice implementation of some RAII patterns.

        In addition, I think new systems programming languages should target to have safety at least par with Rust. That is, free of all data races even for multi-threaded programs by default. Unsafe code should be exception, not the default.

        I’d love to have a language closer to C++ than Rust but with similar safety to Rust but support for class based OO with multiple inheritance. (Or at least interfaces and integrated copy-paste-like logic similar to PHP traits at minimum.)

    5. I actually hate this syntax more than C++. Boiler plate code is the bane of production programmers. It’s what sucks the life out of the creative aspect. And Carbon keeps ramming the type system down your throat. No, please find another way to keep type specification to a minimum or I’ll never write a single line of Carbon code.

    6. I like the idea behind Carbon, but there is nothing I like about this syntax!
      I dont like the type after the variable name.
      var i: i32 = 2;
      should be
      i32 i = 2;
      if constant
      const i32 i = 2;
      “let” doesn’t mean anything to me.

      What is the -> after the function? There is no way I’m using that, also the returned types go at the beginning.
      One more minor thing that is fixable, the first “{” goes on a new line, a lot of people (since JavaScript maybe) started to write code like that and to me it’s unreadable, I know I’m annoying, but I’m really sensitive when it come to syntax.

      Overall, as I already said, I see only negative changes compared to C++ syntax, basically all the new things I dislike are here. Please rethink it, because the idea is good.

      One last thing I would say is that in C++ we need an assembly system like there is in C#.

      1. The redundancy in Carbon’s syntax does not add anything meaningful to that of C/C++; it just restates what has already been coded and gets in the way without adding any meaning. It is irritating to code such syntax to put it mildly.

      2. Even here in the comments of a blog post we can see how violently current C++ programmers will defend current C++ syntax. If it doesn’t look like an unholy hodgepodge of B and Simula, they want no part of it. “Unreadable”!

        It is completely accurate for the author to describe the C++ community as “prioritizing backward compatibility, which prevents fixing technical debt”. I’ve been watching (and occasionally having to use) C++ for decades and this is their guiding star.

        C++ programmers have consistently shown that they are willing to adopt any new language, as long as it’s called “C++”, and doesn’t require them to change a single character in any of their source code from what they’ve been doing since the Borland days.

        Is it any wonder the industry is having trouble finding new C++ programmers, as the old ones retire? If you didn’t grow up learning C++, and live through the politics that produced this Medusa, all you see is bizarre complexity that looks and works nothing like any other modern language.

    7. The syntax seems to be even more complicated than what you see in C++. I understand the general purpose but the futher down I get into the article the stranger Carbon gets, at least from what’s shown in this article.

    8. I think idea behind Carbon is good, but the implementation here is not so good. The declaration syntax is just weird, hard to read, and verbose.

      Anyway, I saw an idea on cppcon that makes a lot more sense than Carbon. It was to create a second, simpler alternate C++ syntax that retires all that technical debt that regular C++ syntax can’t eliminate due to backward compatibility. I really like this idea. It let’s us easily integrate the new stuff without losing out on the stuff we’ve already written, and it let’s us slowly replace our old code with better code over time rather than doing a complete re-write. Much better idea, IMHO.

      1. LOL. I agree! Braces {} are the worst except for all the others choices like begin/end or implied blocking with tab or indentation.

    9. With that syntax I will never look to Carbon.
      Besides that, I would better prefer modernization and improvements for C++.

    10. I find discussions about C++ successors to be quite boring. Especially in the nascent age of generative AI coding. Like I have been predicting for a decade now, the future of compiling does not belong to computer scientists, but rather computer scientists who are trained in the humanities (I hold degrees in both fields). Those who insist on wasting their brains on successor languages (YASL, like YACC, get it?) instead of getting on with the task of tooling are doing just that. Wasting everybody’s dev time.

    11. “keeping in mind the following relationships, it doesn’t fit well”

      Can you explain why you think this? I don’t see C++/Rust as the outlier in your list.

      [A successor] “provides interoperability, optimizes the learning curve and adoption path, and ideally has tool-assisted migration support”

      So this isn’t really about the language design at all, is it? We just need decent C++/Rust interop (but we do anyway), and perhaps “migration support” (whatever that means). As for “learning curve”, Swift is about as different as you can get from Objective-C, and they managed to bring people over with lots of new documentation and educational videos. Again, though, that’s not some special sauce for a “successor language”. That’s par for the course for any new programming language.

      “It’s essentially a superset for its ancestor language.”

      I can’t speak to all of your examples, but Swift is in no way a superset of Objective-C. The syntax, data structures, mutability model, standard library, error handling, memory management, etc. are all completely different. You might as well say that F# is a superset of BASIC.

    12. All these new language designers forget one thing – C++ is so fast because of optimizing compilers. So success of such languages will depend on the code optimization quality, and it is something where it is hard to beat existing C++ compilers.

    13. To allow C++ to evolve in a developer managed way, we should introduce the notion of syntax deprecation flags that are applied at compile time.

      These flags might be defined in a granular way so development teams can incrementally evolve their code bases towards a standard representing “modern C++”.

    14. Why not use or contribute to a language like nim which has good state of the art interoperability with c++, and a pleasant syntax. It is also mature and can be garbage collected or pure native developer’s choice

    15. Rust would seem the C++ successor. However, porting from C++ to Rust involves rethinking and rewriting. For C++, the tooling is amazing, and they’re trying to keep up with greener grass with lambdas and secure coding. It’d be nice if they retired the same number of old bad features as new features added.

    16. Carbon it is more marketing than a viable language. Carbon, like the previous versions, seems to have been designed by technicians, for technicians and not for programmers, even less for system programmers. Any language that does not use some relevant and aesthetic reserved words does not pass the test of time. No serious programmer would waste his time typing “fn” or scrolling through codes with such unsightly terms. An augmented C++ language would be a solution by cleaning up ambiguities and inconsistencies and not a replacement with another language.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Writen by:
    Manuel has been a developer since he was 12 years old he started with Basic, like others, but later also with Modula-2, Pascal, C, Assembler, and these before he was 20 years old. In his professional career, he has used Perl, PHP, Python, Ruby, Java, and JavaScript, and since 2009 he was more on Erlang and since 2016 he started with Elixir and Go. He can be considered a polyglot programmer and he loves to teach and mentor others.
    Avatar for Agi
    Reviewed by:
    I picked up most of my soft/hardware troubleshooting skills in the US Army. A decade of Java development drove me to operations, scaling infrastructure to cope with the thundering herd. Engineering coach and CTO of Teleclinic.