Carbon is not a programming language (sort of)
herecomesthemoon.net
herecomesthemoon.net
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.
"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?"
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".
The issue is that I had to cram them all in somehow, without making the article excessively long. I'm open to criticism, though!
Hopefully Carbon will succeed to achieve this goal.
> The goal is a tool-assisted migration of idiomatic code, not a fully automated migration of all code.
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.
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.
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.
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.
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,...
There's a recent Reddit discussion which had zero pushback against changes but instead people who were disappointed that 2024 Edition won't land all the things they'd hoped for such as the improved Range types†
Without the Edition system we know from C++ that when you say "Why can't we have X?" the defenders appear to tell you that all choices except the status quo are impossible. They will do this regardless of how difficult such a change would be, and so this immediately deflates all interest in incremental improvement. It's a self-fulfilling prophecy.
But with Editions there's a lot of things we definitely can do. Once you open the door to that, it really drives enthusiasm and that enthusiasm can power some of the difficult changes you wouldn't even have considered in the C++ process.
† In Rust syntax like 1..=4 is compiled into the core type core::ops::RangeInclusive<i32> so this is a very natural way to express what you meant, and yet it's not a goofy special case it's just a normal literal like "Word" [an &'static str] or '€' [a char] or 1.2345 [a floating point defaulting to f64] -- however, we now realise these range types made some poor choices and if you made them today you'd make them implement Copy and IntoIterator, whereas the existing types implement Iterator and so in many cases cannot implement Copy. Ergonomically a Copy type would be much nicer here. Can we fix that? Well, the idea is, we make the new types (they exist in nightly Rust in the new core::range namespace but aren't stabilized) and then once we're sure they're exactly what we want we make a new Edition which changes the syntax transformation so that that literal is a core::range::RangeInclusive<i32> instead.
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.
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.
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?
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.
Carbon was officially removed with 10.15 Catalina in 2019 - what's the statute of limitations on reusing a name like this?
When something has been deprecated (like Carbon API which I didn't even know about) then it's imo completely fair game.
Also naming things is surely the most fitting use case for ChatGPT, no?
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.
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.
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
But it isn't that we're directly using this, but that definition checked generics are fairly similar to the ideas in that series of proposals, and that led to the generics in Swift. Also closely related to the generics in Rust, etc.
Um, Catalina is a part of the Tomcat Java application server. Not sure what that has to do with Apple stuff.
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.
What gave you that impression? I'd say approximately 0 people from the Go community and at most 2 people from Rust expected that.
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++.
That's not even close to what Rob Pike wrote on his blog.
What part of "Although we expected C++ programmers to see Go as an alternative" isn't clear enough?
> 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
Abandon is not a synonymous with rewrite, last time I checked a dictionary.
Rob probably assumed Go could displace this. And it's not unreasonable to assume so, although it's closer to a better Java, than a better C++ for this.
Instead it displaced Python for this (not for research/NumPy/Colab stuff), maybe some Java (where it's easier to containerize).
And if it did displace C++, it was in greenfield projects, with non-C++ developers. So it didn't necessarily convert any C++ developers at all.
I could easily imagine him thinking Go could make inroads there. But then it took a very long time to get a flume port, and even then it didn't have half of the nice affordances that the C++ version did.
People say they need the efficiencies of C++, but IMHO they really don't when so much of the actual code time is spent slurping data from one sstable and writing it to the next sstable.
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.
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)
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.)
> 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!
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
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.
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.
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.
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.
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.
My immediate thoughts are: would it be possible to interface with Carbon from Swift, delegating things like memory management of C++ objects to Carbon?
> We consider it a non-goal to support legacy code for which the source code is no longer available
is such a pejorative way to talk about ABI stability.
Yes, supporting code you lost the source for is one use case for ABI compatibility. I guess it’s a real need that some people have. But it’s by far the most unsympathetic use case. It reeks of antiquated development practices. Plus, binaries with lost source are inherently a ticking time bomb since you won’t be able to port the code to new platforms or make any fixes.
But what about all the other use cases for ABI stability?
What if your vendor has the source code but doesn’t want to give it to you?
What if you do have the source, but you want to be able to update libraries without rebuilding every executable that depends on them? Especially valuable if you’re building an operating system, Linux or otherwise. (There’s a reason that Swift spent so much effort on ABI compatibility.)
What if you want to let people build dynamically-loadable plugins? (This one at least gets a brief mention in the Carbon goals document, albeit under the "legacy compiled libraries" section.)
What if you just want to save build time via pre-built libraries?
Don't get me wrong, I'm not against Carbon's decision to make ABI stability a non-goal. There are real tradeoffs in making ABI stability work. I'm just saying, if you're going to explain why you don't support it, don't dismiss the use cases for it by picking such a poor exemplar.
We deserve something better than 1970's view of OS ABIs.
I think you're missing the point of the example in a major way...
Personally, I care about finding ways to support a bunch of these other use cases where we can and in good ways. Especially things like build times, dynamically loaded plugins, and vendored libraries. I think we can and _need_ to find reasonable solutions to those.
The specific example is the only one called out because it's the only one that is fundamentally a non-goal.
The other use cases I think we can find good ways to support, but they may not look like a stable ABI for the entire language. Maybe a designated subset or surface which is designed to have long-term link compatibility in some way, etc. Removing that specific use case is important because it opens up more candidate solutions in the space.
And to be clear, this isn't a straw-person use case. This specific wording and use case was a response to that use case being actively supported by the C++ committee on several occasions.
I'm sure there are cases where this will mean you can write more general and flexible library code, but is it really worth the cost? C++ just seems so full of this three-starred nonsense.
Is it really impressive that Carbon found an abstraction to support it that neatly fits into a Rust-like trait system and generalizes all sorts of things?
Yes.
But I also can't help but feel like maybe the big-brainedness required for all this machinery around the language is of sort of the same stock that created the complexity which made the machinery necessary in the first place? Is this a cultural issue? Is the biggest problem in computer science actually that we have too many smart people?
// read and write variable
player_type["speed"] = &player::speed;