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?


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)?


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


Thanks, this does seem to be the main issue. The key thing is that Carbon is being designed for full C++ compatibility and Rust was not.

Of course it is always an option to add extern "C" glue functions that expose C++ functionality to Rust. I can imagine this is impractical in some scenarios where the Rust-incompatible C++ APIs are very large. Or that the Rust generated bindings are too cumbersome to use and too expensive to rework.

But in those situations I would probably just stick with C++ rather than move to Carbon or Rust. If the dependencies on C++ code are that large, then it may be better to keep it simple with one language. So for myself, I don't see a compelling use case for Carbon.

1 Like

Carbon can have its place with C++, more than Rust.
Carbon focus on a C++ developer in mind, like C++ did with C, you can use your existing header just with an "import" like C++ did with C and include a carbon file in c++ with a simple "include". This will allow usage of third party librairies that provides c++ interfaces to be used in Carbon with the simplicity of an "import" statement.
Also, C++ decisions concerning evolutions of the language follow the ISO workflow that is very very slow! Decisions are taken by some people instead of a community and in my opinion decisions are questionables.
Some voices raised to break the C++ ABI to save the C++, Carbon can fix this by simply adding a super set of the C++ like C++ did with C.

In C++, there is no coherency ( just take a look at module... Each compiler follows it rules about the extension... ), tuple vary if you use the MSVC implementation or GCC implementation ( initialisation order is not the same because is not define in the standard). A bunch of undefined behaviours, STD library is part of the C++ ( std::initializer_list, std::construct_at,...) where Rust take the good decision to separate the STD from the core.

I'm considering the language should make your condition of work better and simpler because language is a tool and like others jobs with complex tool your job become complex and nobody want to complexify his job and his life :smiley:

( Sorry for mistakes, I'm on my phone in vacacion and not a native english speaker :sunny: )

1 Like

I’m very interested in seeing how "C++ interop" pans out. AFAIR (might be wrong), only Objective-C++ provided C++ interop (with Objective-C). It was a common layer enabling the inclusion of both C++ and Objective-C headers and calling into both languages. It wasn’t perfect, and unfortunately Apple removed most online references to it. Nowadays Swift is also tackling C++ interop and there’s a new C++ interop working group.

1 Like

You guys definitely should see the discussion on Carbon on the Haiku forum, which OS is written in C++. It seems that the developers are not very enthusiastic about switching to Carbon:


This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.