[HN Gopher] Carbon is not a programming language (sort of)
___________________________________________________________________
Carbon is not a programming language (sort of)
Author : todsacerdoti
Score : 102 points
Date : 2025-02-08 15:51 UTC (7 hours ago)
(HTM) web link (herecomesthemoon.net)
(TXT) w3m dump (herecomesthemoon.net)
| DashAnimal wrote:
| 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.
| bena wrote:
| 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.
| Mond_ wrote:
| 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.)
| Mond_ wrote:
| 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.
| kayvr wrote:
| FWIW, I thought the bits on governance and history provided
| much needed context. Great post.
| Mond_ wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Did you mean to write "there is is no ambiguity ..."?
| mattigames wrote:
| Too early for that pun, it works better at the end as a
| punchline of sorts, "ensure there is not ambiguity about
| what your intention is is."
| atribecalledqst wrote:
| 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?
| Mond_ wrote:
| 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 wrote:
| 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 wrote:
| 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?
| mrkpdl wrote:
| 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.
| chandlerc1024 wrote:
| (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.
| noelwelsh wrote:
| 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.
| adrian_b wrote:
| 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.
| Tijdreiziger wrote:
| From the article:
|
| > The goal is a tool-assisted migration of idiomatic code, not
| a fully automated migration of all code.
| adrian_b wrote:
| 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.
| eej71 wrote:
| 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 wrote:
| 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.
| hatwd wrote:
| 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!
| rednafi wrote:
| 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 wrote:
| > 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 wrote:
| >> 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 wrote:
| 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.
| UncleEntity wrote:
| Perhaps the reason they didn't see many C++ coders is
| because of this?
| o11c wrote:
| 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.
| nicce wrote:
| 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.
| sapiogram wrote:
| Definitely agree. My theory is that Rob Pike was mentally
| stuck in the 90s, when C++ was still a common choice for
| non-performance-critical entreprise code.
| ncruces wrote:
| It's odd because at Google people still write networked
| servers in C++, which I'd argue, almost no one outside
| Google does?
|
| 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.
| treyd wrote:
| 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.
| gf000 wrote:
| 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.
| steveklabnik wrote:
| 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.
| Mond_ wrote:
| Thanks! Huge fan of your blog. :)
| steveklabnik wrote:
| Thank you, that's very kind :)
| habitue wrote:
| 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_ wrote:
| 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 wrote:
| 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.
| habitue wrote:
| 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"
| zozbot234 wrote:
| 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.
| rvense wrote:
| I 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_ wrote:
| Should 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 wrote:
| Now, 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 wrote:
| Don't you think that it is much much simpler than, for example,
| any of the meta-programming stuff in Python?
| ch33zer wrote:
| It'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.
| mhh__ wrote:
| 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.
___________________________________________________________________
(page generated 2025-02-08 23:00 UTC)