10 ms·
Carbon is not a programming language (sort of)
- DashAnimal 2y agoAs 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.
- bena 2y agoIt 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 2y agoSubreddits 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.
- Mond_ 2y agoThere is a post on r/cpp: https://www.reddit.com/r/cpp/comments/1ikq8kh/carbon_is_not_a_programming_language_sort_of/ 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.)
- Mond_ 2y agoOh 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.
- kayvr 2y agoFWIW, I thought the bits on governance and history provided much needed context. Great post.
- Mond_ 2y agoThanks 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 2y agoThanks 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 2y agoIt'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 2y agoDid you mean to write "there is is no ambiguity ..."?
- atribecalledqst 2y agoHave 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?
- Mond_ 2y agoMeh. 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 2y agoDepends 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 2y agoShoulda 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 2y ago> 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.
- noelwelsh 2y agoWhat 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.
- adrian_b 2y agoI 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.
- Tijdreiziger 2y agoFrom the article: > The goal is a tool-assisted migration of idiomatic code, not a fully automated migration of all code.
- adrian_b 2y agoThat 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 2y agoYes. 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.
- eej71 2y agoI 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.
- hatwd 2y agoInteresting 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!
- rednafi 2y agoI 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 2y ago> 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 2y ago>> 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-exponentially-more.html 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 2y agoThe 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.
- UncleEntity 2y agoPerhaps the reason they didn't see many C++ coders is because of this?
- steveklabnik 2y agoThis 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.
- Mond_ 2y agoThanks! Huge fan of your blog. :)
- steveklabnik 2y agoThank you, that's very kind :)
- habitue 2y agoThis 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_ 2y agoYup! 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 2y agoThat'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.
- habitue 2y agoI 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"
- zozbot234 2y agoThe 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.
- rvense 2y agoI know enough C++ to understand that "member access operator" example, but not enough to have ever seen that before, and my first thought is just "big yikes". 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.
- Mond_ 2y agoShould a modern language support member access operators? Probably not, honestly. 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.
- rvense 2y agoNow, that I won't argue with at all! There are some big-brained people that will find ways forward for various users of C++: some will migrate, some will create impressive tooling, and some, likely will evolve the language as it is - in the grand scheme of things, C++98 becoming an ambiguous term isn't too far off. These are all economic necessities based on just how much C++ has been deposited in the world over the past 35 years. 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?
- drysine 2y agoDon't you think that it is much much simpler than, for example, any of the meta-programming stuff in Python?
- sour-taste 2y agoIt's quite handy in interpreters: read the instruction, store a pointer to the referenced field, then operate on it. That's the only time I used it at least.
- spacechild1 2y ago
- mhh__ 2y agoI 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.
- comex 2y agoI like the idea of Carbon and I hope to use it in the future. But wow, > 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.
- zozbot234 2y agoThere is a stable ABI for these purposes, it's called the C ABI. Or you could use modern "naked functions" support and set up your own function prologues, epilogues and parameter passing in assembly code.
- pjmlp 2y agoIts clunkiness in modern times is why I rather deal with COM boilerplate, or OS IPC. We deserve something better than 1970's view of OS ABIs.
- JackC 2y agoI think the distinction is these usecases require an ABI, but not the same ABI? You could in theory migrate both sides to Carbon for all of these, if it was worth it.
- Remnant44 2y agoI 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 2y agoI'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 2y agoWorking 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?
- theanonymousone 2y agoBased on what I read, can we say Carbon is the Python 3 of the C++ ecosystem?
- binary132 2y ago“We should simply replace the Committee with Google” is not a compelling reason to switch to Carbon. It’s actually kind of the opposite of that.
- Mond_ 2y agoHave you read the section of the article addressing this concern?