Just saw this Carbon Google C++ replacement


carbon-language/carbon-lang: Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README) (github.com)

Greetings Rust fans

No flames please, I just saw this in r/Rust Reddit, re-posting here for comments, thoughts, etc.

For me the big ticket item coming from Carbon is C++ bidirectional and relatively seamless interop.
I would love to see Rust with something similar allowing easy re-use of C++ libraries and C++ with easy ability to use Rust crates.
Without the interop feature I can not ever see Rust succeeding C++.
My my personal observations, I can and I have been wrong before.


Fun point: Carbon officially recommends to use Rust instead of it if you can. But if you're one of those poor souls like google with billions of lines of existing C++ code you must directly interact with, and your C++ code follows google style like noexcept everywhere and statically link everything, Carbon can be a viable option for you.


Thanks for your thoughts.
I am not a C++ programmer by any stretch (I tried C++ and I really disliked it).
But in C++ defense I am guessing that Microsoft, Google, AWS, and all other software giants all have similar C++ issues today - many massive and aging C++ code bases.
None of these code bases will likely to be replaced/retired in coming decades or two. Which means that any C++ (and C) successor needs to provide good integration/interop story to be able to have any chance of success.
Rust has some answers for C (albeit not perfect) and none for C++.
What am I missing?


Of course it does - there is cxx as the base. Google then made autocxx on top of that for integrating with their existing codebase.


thanks, I was not aware of cxx and autocxx (I dont work with C++).

Which begs another question, what is Google really trying to achieve with Carbon, if Rust has a solid answer to the C++ interop?

1 Like

I think you are under the impression that there is exactly one solution for everything in Google. Although I have never worked there (I am still in college), by working in some of their open-source projects, it is apparent to me that engineers over there will come up with their own solution, even though there exists a solution. Google doesn't seem to mind, and as a result we have a situation like this.
Which I guess is good - the more, the merrier right?

1 Like

When I was much younger it was called a "not invented here syndrome"
I expect much more from Google, they are much better than that.
As an industry we already have more programming languages than we can effectively handle and absorb and it has become counterproductive.
The languages that lasted the longest and had the largesat code-bases were the ones where every company and university has adopted, such as COBOL (yes, it still runs mission critical stuff), C, C++, Java. All of them have major warts but they delivered because everyone adopted them.
IMHO. Apologies for the rant.


I don't think that's a particularly helpful way of putting it, or that it's an important criterion at all. C++ is not going away anytime soon, realistically, due to its enormous legacy. But if there's no legacy code to worry about, you can always just start a new project in Rust. So completely replacing C++ is not a realistic goal, and the realistic goal of being a new, better C++ alternative is already possible without C++ interop.

Rust has already achieved things that C++ couldn't, for example, it was considered as a second language for developing the Linux kernel. Previous attempts to bring C++ into that were met with sharp opposition on part of its author.


I thought it was clear in my original post and initial replies that I never meant to say or imply that Rust was a to be replacement for C++. A successor is not the same as a replacement. Interop is required so that Rust and C++ can co-exist easily and productively for next few decades and such that Rust can re-use the vast C++ ecosystem and C++ could also do the same. There is always going to be "legacy" in the areas where C and C++ currently serve.

1 Like

It sounds like you think of Google as one entity with a single comprehensive vision, but the reality is they are an organisation with about 150,000 employees that all have their own values and agendas.

If someone sees a particular pain point in the organisation that could be relieved by creating a new tool, then it's perfectly fine for them to spin off an experiment to see whether they can do something about it. In this case, the Cargon team is seeing if there is an easier way to write fast code without throwing away the billions of lines of C++ code that already exist.

That's fine. Think of it as evolving programming as a discipline via natural selection.

The harsh reality is that 99.9% of new programming languages will die without more than a handful of people hearing about them or using them. However, as a community we still gain from the knowledge that was gained through their implementation.

As an example of what I mean, Rust mentions the Cyclone language as an inspiration for region based memory management (i.e. lifetimes). Now, I've never heard of this language and it doesn't even get a mention in the top 50 languages list, yet because of the work they've done other people were able to iterate on their idea and produce something wonderful.

Often, by creating a new language you can try out different ways of viewing a problem very quickly without 20+ years of baggage that you've got to stay compatible with. Good luck trying to get a completely new concept (e.g. dependent types or dynamic typing) into an established language like Rust or C++ at this point. Then, even if you manage to get the new concept into the language, you run into the problem C++ has where people complain about it being bloated, inconsistent, and full of gotchas.


True, but not in this case. If you have Googler friends you may ask them to look for the cppnext website. It starts with this premise: C++ has serious issues that we haven't fixed so far, despite trying. We want to understand whether existing languages could be used to replace (not supplement) C++ at Google, and what doing so would cost.

And then you would find two top current contenders are Carbon and Rust. Just don't get your hope up: this and this were visble parts of these efforts.

Looks like the pressure to replace C++ with something safer is becoming more acute thus Google have gone open with their plans.

It's more serious than that. Google really wants to jump C++ bandwagon (emphasis on the replace and addition of (not supplement) leave no doubts about their desire). But they don't want to lose investment into tools developed with C++ help.


What I picked from the Carbon language docs.

Carbon is for organizations and projects that heavily depend on and have a large part of their codebase written in C/C++."
Carbon means to facilitate these organisations with the prospect of migrating away from C/C++ like what Kotlin is to Java and TypeScript is to JavaScript.

Also, engineers have been encouraged to use any programming language that is technically and economically viable for a project when Carbon doesn't fit.

Overall, I believe this to be highly ambitious and that Google has a high chance of succeeding with this experiment so it'll be exciting to see how it pans out.

Finally, will Carbon replace C++? My answer to this is, not yet.


Seems to beg the questions:

  1. If Rust's C++ interoperability were more seamless (along the lines of what will be possible with Carbon) would the need for something like Carbon be significantly reduced?

  2. Would adding this type of C++ interoperability for Rust be practical, or would it add too much complexity (implementation and/or usage)?

1 Like

It doesn't matter since Google is a company that tends to invent everything that it can possibly can within limits of profitability.
From what I've heard, they have their own version of almost every piece of software we normally use.
So, even if Rust had drop-in compatibility with C++ (which is technically very difficult or impossible), I think they'd still create Carbon, just because they can and also because they can control it fully.

Do you mean into the language? I doubt that.
C++ interoperability is a very different beast than C interoperability. For calling to and fro from C code, all you really need are stable function names, C calling conventions and C struct layout (approximately speaking).
For calling to and fro C++ code, well strictly speaking you can't since C++ doesn't have a stable ABI. cxx works around this by generating "extern C" "glue" functions on both Rust and C++ side. These call each other, but are auto-generated so you don't need to bother.
Not sure how Carbon does this though.


The major problem is that c++ have features that are simply not compatible with Rust.
A list is here : Generating Bindings to C++ - The `bindgen` User Guide