Carbon is not a programming language (sort of)
97 comments
·February 8, 2025Mond_
kayvr
FWIW, I thought the bits on governance and history provided much needed context. Great post.
Mond_
Thanks a lot! When writing something like this it can be hard to keep in mind what your average reader is familiar with.
"Do I need to get into the history and the structural process of the C++ Standard Committee? I'm sure everyone already knows about that, right?"
piebro
Thanks for the post, I enjoyed reading it.
There is a small typo in this sentence: "As long as we’re willing to say that Carbon is is about reducing the reliance on the C++ Standard Committee ...". There are two "is".
PaulDavisThe1st
It's a hangover from the ill-fated Clinton programming language, where you repeat an operator (such as "is") to ensure there is no ambiguity about what your intention is.
zelphirkalt
Did you mean to write "there is is no ambiguity ..."?
funkychicken
You mentioned that std::unique_ptr had a runtime cost (versus a raw pointer). I had always assumed the compiler would optimize any of that away (if you have the default deleter). Could you explain what you meant?
saagarjha
I assume this is the example presented here: https://youtu.be/rHIkrotSwcc?t=1050
funkychicken
Oh thanks! That’s really depressing though, I feel like my whole world view has been shattered lmao
scrubs
Technically kind of interesting ... but as a writing piece it's a mess of mushy, roundabout, haphazard points. With every line I read I can just hear my uni English prof in my ear yelling.
Mond_
I can live with that, I think. I'd like to believe that all of the points are relevant.
The issue is that I had to cram them all in somehow, without making the article excessively long. I'm open to criticism, though!
adrian_b
I have no idea whether Carbon will be successful, but this is the only right way of evolving a programming language when incompatible changes must be made: by providing tools that guarantee a completely automatic migration of the legacy programs.
Hopefully Carbon will succeed to achieve this goal.
eej71
I think the idea of "when incompatible changes must me made" has caused much harm and damage to various language projects. I'm specifically thinking of the damage done as part of the python 2->3 changes and to a lesser extent the damage done with the original conception of what was called perl6.
C++ is definitely in a tough spot on the evolutionary trail. But the idea that the only path ahead is through incompatible changes seems likely to produce the same harmful effects.
tialaramex
In 2019 Epochs was proposed for C++. That's "too late" for C++ 20, but only by convention. Epochs proposed to give C++ a way to evolve while retaining better backward compatibility, much like Rust's Editions (the 2024 Edition stabilized last year and will ship in Rust 1.85 in a week or two)
Instead C++ has added all sorts of slightly incompatible features every three years since 2011, and is expected to do so again, periodically one of these incompatible changes is especially troublesome for important people and, like a naughty toddler, the committee promises not to do that again.
Yet, despite these incompatible changes which might have accidentally larger consequences than expected, for fear of the consequences other changes which were known to be incompatible but seem "worth it" are rejected. The worst of both worlds.
pjmlp
In practice, epochs offer little more than -std=lang-version, because they only cover grammar changes, and a few selected semantics.
There is no plan for binary libraries across epochs, how different implementations would interact with each other, how multiple crates requiring different versions would interact with each other if their public API crosses versions with different semantics,...
Doxin
> I'm specifically thinking of the damage done as part of the python 2->3 changes
Though on the other hand, we can only the imagine of not doing those changes. I reckon it would be at least as bad as the 2->3 changes. At the very least I wouldn't want to go back to a world where bytes and strings were unified.
pjmlp
C++ already had quite a few incompatible changes, your C++98 code will not compile in a C++23 mode compiler, if lucky enough to use one of such features.
eej71
Ok, so could we agree that then doubling down on even more breaking changes is likely to create more codebases stuck at these "evolutionary bottlenecks"?
Whenever I hear someone say - "Gee, the only path ahead is a breaking change, sorry charlie!", what I really hear is - "I gave up thinking up a solution on how to do it an evolutionary way and I am lazy and just want to declare a revolution!".
There is always a pathway ahead on the evolutionary path. That's the premise at least.
jcranmer
The real problem with ABI breaks isn't so much the need to (automatically or manually) migrate legacy programs, but that so much of modern software is comprised of multiple pieces that don't have any way to coordinate a lock-step ABI migration.
Take something like std::unique_ptr. The basic problem is that it is absolutely capable of being written such that std::unique_ptr<T> has the same ABI as T, but it doesn't (instead acting as a T*). It's pretty damn trivial to write the necessary thunking between the ABI versions, so it's also absolutely possible to have both old-ABI and new-ABI coexist (something that was a lot more difficult for the infamous Python 2->3 transition). And other than the internal changes needed to give it a new ABI, there's not really any user-visible API that would need to be migrated. But it still can't be done because std::unique_ptr is used on the interface between library A and B, and how is A supposed to know which version of the ABI B is expecting, when neither A nor B?
Tijdreiziger
From the article:
> The goal is a tool-assisted migration of idiomatic code, not a fully automated migration of all code.
adrian_b
That is just an acknowledgment of the fact that for something as complex as C++ a fully automated migration is unlikely to be achievable.
This does not mean that they will intentionally avoid to make possible a fully automated migration.
Normally the migration tools should be designed to attempt to do a fully automated migration, but whenever there are corner cases for which the effort to handle them completely automatically would not be worthwhile, then human intervention shall be required.
tialaramex
Yes.
In C++ in particular one of the most obvious ways to write unmaintainable C++ which such automation couldn't be expected to migrate is via abuse of the pre-processor.
C++ retains the entire C pre-processor, which is a weird not-quite-language-agnostic text macro language on top of C. We can abuse this to write a different programming language, with different rules, and then at compile time the pre-processor transforms it into C++ which compiles.
I'm confident a migration tool could not always usefully translate this, and I'd argue that's not a failing of the tool so much as an inevitable consequence of writing this unmaintainable code.
owlstuffing
> but this is the only right way of evolving a programming language when incompatible changes must be made: by providing tools that guarantee [it]
Yep. I'm not a particularly big fan of Google languages, but focusing on bridging legacy code is brilliant.
Would have been interesting if Oracle had done the same with Java shortly after acquiring it. Java is so hemmed in by legacy compatibility it basically can't make any significant language or VM changes without making harsh compromises. Of course, Oracle would likely have supported legacy Java indefinitely, and made a fortune supporting/licensing it.
atribecalledqst
Have to say, it bothers me a little bit that they named it Carbon. I associate that term strongly with the old Carbon API from Apple.
Carbon was officially removed with 10.15 Catalina in 2019 - what's the statute of limitations on reusing a name like this?
chandlerc1024
(Carbon lead here)
We tried other names, but we found collisions with essentially all of them. =/ We ended up picking a "least bad", and actually talked to a couple of folks familiar with the old usage to see if it was a worse collision than we realized. They weren't delighted but generally shrugged. So here we are. =/
It's definitely not perfect, but I think it's much more searchable than "C" or some other choices. Ultimately, I think its at least not bad enough to matter compared to the actual project.
phaedryx
Why not create a word/name? e.g. Clojure
chandlerc1024
We played with some, but none stuck.
A big goal was being short and easily pronounced, including by non-native English speakers, in a recognizable way from reading the text. That made the overwhelming majority of "fun" spellings not work well.
On one hand, I feel like we're just not as good at naming as Rust and Zig. Both of those names are :chefskiss:
On the other hand, Carbon does have a bunch of awesome puns waiting for us... So we've got that going for us. =D
theanonymousone
Cloce
mrkpdl
I feel the same, especially given how significant Carbon was to the revitalisation of Apple. Without carbon they likely would have lost several key developers in the Mac OS X transition, which all of their later success stems from.
krackers
If this takes off, it will end up poisoning search results for anyone interested in retrocomputing.
Mond_
Meh. There's only so many good names out there. When there's little risk of confusion it's usually fine.
When something has been deprecated (like Carbon API which I didn't even know about) then it's imo completely fair game.
stevefolta
Depends on your definition of "a good name". It seems like yours includes "must be a short English word", but doesn't include things like "is easily web-searchable" and "doesn't conflict with existing names". Throwing out the "short English word" criterion opens up a universe of names like "Wubulus" or "Flarnit".
jimbob45
Shoulda named it “stroopwafel” in honor of Bjarne Stroustrup. Never mind that one is Danish and one is Dutch.
Also naming things is surely the most fitting use case for ChatGPT, no?
lproven
> like Carbon API which I didn't even know about
Yeah, I hear that kind of excuse a lot.
Last time, someone had come up with some kind of new database-oriented language or something and they called it "Limbo".
Limbo is the programming language in Inferno. Plan 9 is what the Unix creators did next -- it's UNIX 2. Inferno is UNIX 3; it's what Plan 9 developed into.
It is the next language from the team that developed C.
It may not be widely-used but it's important, significant, and just as someone knowing their history makes me take their work more seriously, someone not knowing their history makes me think they have less to contribute, because they clearly haven't gone looking at prior art.
Ignorance is no excuse.
For someone to know what they're doing, they need to have at least a vague idea of whose shoulders they're standing on (as Isaac Newton put it). If they don't, they could be reinventing a wheel, and if they call things "struts" and "roundbuffers" and "spinny-pivots" then this says they don't know about "spokes" and "tyres" and "hubs". And making it hexagonal.
The flipside of this coin is making life easier for the community to search and learn.
anonnon
I've never done any Mac programming, yet that was my reaction when I heard about it. Why would you choose that name for anything C++-related?
tbrownaw
> Carbon was officially removed with 10.15 Catalina in 2019
Um, Catalina is a part of the Tomcat Java application server. Not sure what that has to do with Apple stuff.
rednafi
I haven’t written C++ since I graduated and hopefully won’t have to, but this looks really good.
While I love Go, I feel like languages like Go and Rust didn’t become C++ killers because they expected everyone to jump on the bandwagon and abandon all their legacy code. That didn’t happen.
This approach of keeping the interop intact might just work.
sapiogram
> I feel like languages like Go and Rust didn’t become C++ killers because they expected everyone to jump on the bandwagon and abandon all their legacy code
What gave you that impression? I'd say approximately 0 people from the Go community and at most 2 people from Rust expected that.
npalli
>> I'd say approximately 0 people from the Go community
Quite literally that's what Rob Pike (golang co-creator) thought was going to happen
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
sapiogram
The person I responded to said that "they expected everyone to jump on the bandwagon and abandon all their legacy code".
That's not even close to what Rob Pike wrote on his blog.
nicce
Very odd to hear that from Golang co-creator. I don't really see how Go actually could compete with C++. Maybe in few cases, when people have accidentally chosen C++ incorrectly for their projects.
o11c
It really shouldn't be a surprise given that it took until 2022 to implement one of the basic features that everybody relies on constantly.
treyd
Go isn't a C++ killer because there's very many usecases that C++ is commonly used for where having a runtime with a GC are absolute nonstarters. Other downsides it has is somewhat janky and slow FFI to C, limited control over how/when data structures are copied, and green threading making granular control over processes, forking, shared memory, etc harder. These are all common things that are expected in systems programing and ever presenting it as one is dishonest.
Rust doesn't suffer from any of those issues and had a feature set comparable to that of C++ from before even 1.0, so there is actually a tenable argument that it could be a C++ killer. That didn't quite manifest because there isn't a strong reason to rewrite existing large C++ codebases, but most kinds of new projects that would have been written in C++ in like 2010 have increasingly been done in Rust instead.
milesrout
Go is a C++ killer in a different sense: there are things that people would have written in C++ (or often in C) that are today often written in Go instead. Not everything, obviously. But Go is a great Unix glue language for programs too big to write in Shell and often those would be written in C or C++ in the past.
baranul
Agree with your statements. Go's history on its Wikipedia page[1] and other sources, explains one of the original points that led to its development was "dislike of C++", where it was causing them all kinds of problems at their office (explained in other sources).
Go was used to replace it, where possible and for their purposes, but not in a 1 to 1 way. That's neither a total replacement for C or C++, but rather a replacement in particular areas they deemed important. Carbon, on the other hand, is going that extra step where the creators of Go didn't want to.
[1]: https://en.wikipedia.org/wiki/Go_(programming_language)
gf000
Go doesn't even play in the same niche as C++, the part that could have been replaced by a managed language was long replaced by Java.
pjmlp
With a much more modern type system.
ReflectedImage
That's part of the point it's from the software engineering viewpoint of preferring simpler typing systems rather than the academic viewpoint of preferring more complex typing systems.
DashAnimal
As someone who uses C++ daily, very excited for Carbon. I really align with the goals they have set. Its a shame communities like r/cpp block any discussion of successor languages but I hope once this language starts gaining more momentum and nearing release, it will begin to market itself and get more attention.
Mond_
There is a post on r/cpp: https://www.reddit.com/r/cpp/comments/1ikq8kh/carbon_is_not_...
For now, anyway. Let's see how long it survives. (+1 to being excited for Carbon. That shouldn't be a surprise though, considering I wrote this article.)
bena
It depends on the aim of the community. If it is to discuss the language, advancements, tips, etc. Then restricting talk of other languages makes sense. Otherwise the subreddit can become just talk of replacement languages.
Boldened15
Subreddits sometimes split the difference by dedicating a single day of the week where something is allowed, eg. only allowing you to post questions on Fridays, or creating threads to consolidate off-topic discussion.
steveklabnik
This is a great post! I'm very intrigued to see how Carbon ends up. I've also enjoyed reading about some of their implementation choices, being more data-driven.
hatwd
Interesting language - its syntax looks like a mix of Rust and Go, with a few of its own idiosyncrasies to distinguish it from those languages.
> Carbon is a concentrated experimental effort to develop tooling that will facilitate automated large-scale long-term migrations of existing C++ code to a modern, well-annotated programming language with a modern, transparent process of evolution and governance model.
This is probably where Go and Rust fail to be C/C++ "successor" languages, as interop between those languages doesn't seem to be as seamless as Carbon aims to be.
Will keep an eye on its development!
habitue
This immediately suggests what you want is a gradual migration process from one language through several intermediate languages to your target language.
i.e. instead of a big bang C++ -> Carbon migration, instead you want something like:
C++ -> C+++ -> Carbon-- -> Carbon -> Carbon++ -> Rust
(Basically fake names for more gradual transitional intermediate languages, assuming Google would like to have everything in Rust eventually.)
The key idea of "targeting automated migrations" makes this kind of thing feasible
Mond_
Yup! I didn't work this into the post, but this is in fact exactly (more or less) the goal.
Chandler even explicitly says "Maybe we can eventually convert some future version of Carbon to Rust, who knows."
Whether that is going to happen (or is viable) is unclear for now, but it's pretty clear that a migration of C++ to (idiomatic) Carbon will probably involve at least a few steps.
IshKebab
That's not really possible. Rust isn't "C++ but better". It has several design decisions that make it not really compatible with C++, e.g. no move constructors & the use of fat pointers.
zozbot234
The main obstacle to making Rust a "C++ but better" language is arguably the half-baked design of its support for pinned data. (Because "pinned", i.e. location-sensitive objects that can't simply be memcpy'd elsewhere are ubiquitous in idiomatic C/C++.) But there are several language proposals to mitigate this in the future, though for most of these a full transition will require an edition change in order not to break backward-compat.
As for the use of 'fat' vs. 'thin' pointers for dynamic dispatch, a C++-style vtable ptr is just a &'static VTableStruct, where VTableStruct is a dictionary of functions. The anyhow crate is a good example of how you can implement that particular approach.
habitue
I think I'd say "it's hard, and would require making some opinionated decisions as to what to convert something to" vs "not possible". The bar is pretty high for "not possible"
noelwelsh
What I've seen of Carbon looks really good. I feel they're trying to do something that is hugely ambitious, and so perhaps unlikely to succeed, but I love the vision.
As I don't have a massive C++ codebase I have no stake in Carbon's success, but I think language improvements are some of the most significant steps we, as an industry can take (language improvements are basically the only way we can rule out entire classes of bugs) and I want our industry to improve.
mhh__
I highly doubt I'll ever use Carbon but I'm really enjoying their statements of their ideology and choices on various matters in the github repo.
Remnant44
I thought this was a well written and fair article. My preference would be that C++ is not "forked", but I understand the reasons for the impasse and consequences.
I found the part about member access operators interesting.
I've written C++ for 25 years, and although I've used "pointer"-to-member(function/fields) ability many times (indeed, this is how you bind signals to your member slots statically in QT!), I had no idea that it could both be null, and that -1 was used for a 'null' 'pointer' in this instance.
Good example about how large the language is, with so many weird dark darks. The number of air quotes needed above is pretty illuminating on its own.
Neywiny
I've heard that null pointers were greatly regretted. My favorite example of their issue is that there exists embedded devices with memory at address 0. Even worse, it's ITCM (instruction memory) so one might think that on startup you may want to copy a block of program code into it for lower latency (such as ISRs). Maybe you want to point the DMA to that while the CPU is busy initializing other things. But you can't. Because the driver code checks for... A null pointer where that's defined as 0.
Also, anything that doesn't do a null check (failed malloc anyone?) ends up writing to that memory. Good luck if you need it for something.
Similarly when I was writing a simulator for the chip I ended up commenting out that block for a lot of it because it was masking so many issues as other issues.
Unsure if newer generations moved it to somewhere else.
willtemperley
Working on a Swift project which is integrating an irreplaceable C++ library, this is really interesting.
My immediate thoughts are: would it be possible to interface with Carbon from Swift, delegating things like memory management of C++ objects to Carbon?
Oh hey, that's my post.
HI HACKER NEWS! Excited to see you!!! Ping me if you find typos.
(Also jeez, writing this took way too long and I spent too much time editing it trying to cram everything from Cpp2, the Google governance issue, member access operators as a case study, some historical bits, etc. into the post.)
EDIT: One of the most interesting things for me is that (so far) no one complained about the lack of Carbon code examples.