[HN Gopher] Carbon Language: An experimental successor to C++
___________________________________________________________________
Carbon Language: An experimental successor to C++
Author : samuell
Score : 87 points
Date : 2025-07-31 14:23 UTC (8 hours ago)
(HTM) web link (docs.carbon-lang.dev)
(TXT) w3m dump (docs.carbon-lang.dev)
| bananapub wrote:
| [2022]
| Jtsummers wrote:
| It's an ongoing project, specifying a date here wouldn't make
| much sense.
| bananapub wrote:
| is there any news? the website has no information and doesn't
| really highlight anything other than their launch at a
| conference in 2022.
| pjmlp wrote:
| The information is scattered around the Wiki, LLVM and C++
| related conferences.
|
| Basically there should be a 1.0 somehow towards the end of
| 2026.
|
| https://github.com/carbon-language/carbon-
| lang/blob/trunk/do...
|
| This is a talk from last year CppNorth, there should be one
| this year as well,
|
| https://youtu.be/8SGMy9ENGz8?si=reukeBjxAOivX6qI
| Jtsummers wrote:
| Yes. pjmlp answered here, but before he posted his reply,
| nxobject commented with the roadmap which covers 2025 and
| beyond:
|
| https://docs.carbon-lang.dev/docs/project/roadmap.html
|
| Even on the submitted page, the oldest you could claim it
| represents is 2024. But I stand by my earlier remark. When
| linking to an active project's documentation or home page,
| unless it's to a specifically dated version of it, a date
| doesn't make sense. For instance, linking to something
| specific in Python 2.6 documentation, maybe add a date. But
| if it's just to python.org, it would be absurd to tag it
| with [1991].
| nxobject wrote:
| If you've seen this before, it's worth looking at the 2025
| roadmap - it's long-term work, a full safety story hasn't been
| quite figured out (TBD end 2025), and 0.1 is TBD end 2026. About
| the pace of Rust, although without the active forum that Rust had
| in its early days.
|
| https://docs.carbon-lang.dev/docs/project/roadmap.html
|
| What _is_ interesting is that I get the impression that Carbon is
| being workshopped with the C++ community, rather than the wider
| PLT community -- I worry that they won't benefit from the broader
| perspectives that'll help it avoid well-known warts elsewhere.
| ryanobjc wrote:
| I think there are parallels with functional languages on the
| JVM. The parts that are the worst are the parts that were built
| for maximum interoperability. Not to mention that the JVM
| forces classes on you at the deepest opcode levels.
|
| Compatibility with C++ is fine, but so far it seems carbon's
| safety story is entirely a wishlist rather than anything yet.
| Seems like Carbon might be a more of a place to demonstrate
| features for C++ committees than a real language?
|
| Personally I have hand it up to here with lousy programmingn
| languages that make it easy for me to write bugs.
| IshKebab wrote:
| > being workshopped with the C++ community
|
| Honestly seems like a dubious idea. The C++ community that
| remains are even more "just get good" than before. They still
| think UB all over the place is fine.
| bla3 wrote:
| I think that might be true of the language committee, but
| there's presumably a huge crowd of people with existing c++
| code bases that would like to have a different path forward
| than just hoping that the committee changes priorities.
| pjmlp wrote:
| That is what many of us have done moving into managed
| languages, with native libraries when required to do so.
|
| The remaining people driving where the language goes have
| other priorities in mind like reflection.
|
| The profiles that were supposed to be so much better than
| the Safe C++ proposal, none of them made it into C++26, and
| it remains to be seen if we ever will see a sensible
| preview implementation for C++29.
| wocram wrote:
| Carbon is just trying to bring a rust-like edition to cpp,
| there's no reason for non cpp users to Carbon.
| pjmlp wrote:
| Main goal for Carbon is to port existing code first, general
| purpose second, with Google internal teams as main customer.
|
| If it ever goes beyond that remains to be seen.
|
| The Carbon team is the first to point out that anyone doing
| green field development should reach out to Rust or any managed
| language that fits the project scope.
| mihaic wrote:
| It's become a pet peeve of mine, but for the love of God, if
| anyone with input in Carbon is scanning this, what can be done to
| use "func" instead of "fn" as a keyword?
|
| That all-consonant keyword always makes it seem like I'm reading
| Hungarian notation when reading Rust for instance. An other
| options I've seen for instance in Pony, "fun", is already an
| English word with a completely different meaning.
|
| Even the "function" from Javascript seems fine to me.
| seanw444 wrote:
| I kind of appreciate fn, personally. It's nice having function
| declaration lines with two less unnecessary characters in their
| length.
| flohofwoe wrote:
| Tbh, I wonder why modern languages still have a function
| keyword at all, e.g.: const add = (a: i32, b:
| i32): i32 => a + b;
|
| ...or any variation of the arrow-function idea...
| uncircle wrote:
| It's hard for a naive parser (one-token lookahead, for
| example), to tell after parsing `const add = (` if this
| defines a function or a variable.
|
| A "function" keyword often exists just to help the parser.
| C3, for example, to simply the parser of its language that's
| a superset of C, adds a "fn" keyword for this very purpose of
| disambiguation.
| popcornricecake wrote:
| That looks like a variable that points to an anonymous
| function. For simple small functions here and there it may
| not matter, but if the entire call stack in a debugger is
| full of anonymous functions then it could be a problem.
| kibwen wrote:
| It's the other way around. Modern languages and grammars use
| explicit leading keywords to clearly indicate what sort of
| context they're about to parse, rather than blindly forging
| ahead in a superposition while waiting for some future
| sequence of tokens to clarify what the context is.
| klibertp wrote:
| You're assuming that named lambda is the same thing as a
| function, which often isn't true. Unless you mean that `=>`
| should be ambiguous depending on scope (lambda inside a
| function, a function in global scope)? That would also be a
| bit problematic, wouldn't it?
| mckravchyk wrote:
| C++ does not have a function keyword at all, I wonder why did
| they add it in the first place.
| twoodfin wrote:
| To avoid any possibility of reintroducing the Most Vexing
| Parse?
|
| https://en.wikipedia.org/wiki/Most_vexing_parse
| Tuna-Fish wrote:
| The c++ notation for functions (and types in general) is
| horrible, and makes parsing much more expensive than it needs
| to be. Fixing it is step one if you are making a modern
| language.
| pjmlp wrote:
| A compatibility required by C.
| gpderetta wrote:
| It doesn't, but you can pretend it does: auto
| my_function(int, double) -> int;
|
| They probably want to use the same arrow signature and need
| something in place of auto as omitting it completely would
| complicate parsing.
| cyber1 wrote:
| "func" is fine; "function" is too long. "fn" is also good, but
| for example, Go was designed with "func," and it's one of the
| most successful, readable languages in the world, so why not?
| gpderetta wrote:
| In C++ you can use indifferently either the class or typename
| keyword to introduce template arguments (because of course you
| can). A lot of styleguides suggest using typename because class
| is slightly misleading (the type could be anything not just a
| class).
|
| In practice everybody just uses class, because who as the time
| to type the full keyword and signature declarations in C++ are
| already unwieldy as it is.
| pjmlp wrote:
| Anyone using a proper IDE instead of notepad like editor.
| gpderetta wrote:
| I do use a proper ide with with clangd completion and all
| kind of helper macros, but I can still type 'class' faster
| than I can trigger completion.
| lvass wrote:
| I use emacs' prettify-symbol mode to turn every language's
| function keyword into fN. Don't think I incurred in God's wrath
| just yet.
| Imustaskforhelp wrote:
| Why not just write it as fun, that way you are having fun
| while writing a function just as (God intended,[pun
| intended]) :P
| zigzag312 wrote:
| I like it the most when there's no keyword. Just name() and
| return type.
| munchler wrote:
| F# uses "fun" and I like it. The vowel does help a bit and I
| never confuse it with the English word. The worst one IMHO is
| Haskell's "\".
| dismalaf wrote:
| Pony's keywords are the best. "fun" and "be" are just, well,
| fun lol.
|
| I agree, I hate fn. Also not a fan of func though.
| pton_xd wrote:
| How about "proc"? Too different? I don't like fn either but
| function is too much. Fun and func aren't great either. I'd go
| with proc or fn.
| pjmlp wrote:
| fun, press tab, modern IDE fills in the remaing function
| characters.
|
| Unfortunately we keep designing languages for people using
| notepad.
|
| Nowadays my editor even writes full blocks at a time.
| AnimalMuppet wrote:
| If "fun" and "func" are already "not great" (because, I
| presume, they're too long), then "fun[TAB]" is _not_ the
| solution.
|
| Mind you, I'm not saying that your solution doesn't work.
| Just that it doesn't work _for the GP_.
| treyd wrote:
| What's wrong with fn? It's perfectly understandable. I don't
| understand what the bikeshedding about keywords like this is
| about.
| Imustaskforhelp wrote:
| I don't even code in kotlin but I know that kotlin has
| function as fun :P
|
| Such small things as using __ __ in python and small
| inconveniences (lua's 1 instead of 0) really has a lot of
| people, what do I say.. yea, polarized on this matter.
| mihaic wrote:
| Keywords usually are quite pronounceable, and some of them
| are even proper words. How do you read fn?
| steveklabnik wrote:
| fun
| bhawks wrote:
| Since interop is such a big design goal I wonder if fn was
| chosen after analyzing the impact of alternative keywords
| present in large c++ code based that would impact interop in a
| negative way (eg requiring more escaping).
| darksaints wrote:
| I remember back when Rust was still in so much flux that there
| were regular discussions about syntax, and there was a proposal
| very similar to the syntax of carbon: square brackets for
| generics and type annotations, parens for indexing, etc. It was
| basically turned down because they wanted to win over C++ devs. I
| still wish it was the favored outcome...it looks so much cleaner
| and less jarring.
| kibwen wrote:
| Nah, IMO they're both pretty suboptimal, and if Rust is going
| to choose between two bad options, it might as well choose the
| overwhelmingly familiar option. (Sadly, my strong opinions on
| what type parameter and indexing syntax should look like are
| too large for this margin to contain.)
| gpderetta wrote:
| The joke is that no* c++ dev actually likes the bracket syntax
| for templates.
|
| * I might be slightly exaggerating.
| self_awareness wrote:
| It's strange that they sometimes use [] to specify a type, other
| times they use (). That doesn't look very consistent to me.
|
| I like the use of [] though, it reminds me of Scala, which I
| liked before they did the scala 3 fork.
| Arnavion wrote:
| `fn partition[T: ...]` uses `[]` to define T. `s: Slice(T)`
| uses `(T)` to invoke the type constructor `Slice` with the type
| argument T. So you could say that's fine because these are
| different operations.
|
| But then defining a type constructor itself still uses `()`,
| like `class UnsafeAllowDelete(T:! Concrete) { ... }`. It does
| seem somewhat inconsistent.
| cjj_swe wrote:
| How is it inconsistent? The square brackets always mean "this
| was deduced" and the parens always indicate "this was passed
| in explicitly"
| cjj_swe wrote:
| Square brackets do not indicate "this is a type". Instead they
| indicate "these things were deduced from their context"
| Jtsummers wrote:
| [] here can be read as similar to <> in Rust, C#, Java, or C++
| templates (but move the content after the `template` into the
| function declaration). It's not weird if you're familiar with
| generic programming (and C++ programmers, the target audience
| of Carbon right now, will all be familiar with it, they use it
| with their STL algorithms and collections if nothing else). The
| () is the ordinary "here is the parameter list" used in pretty
| much every C-syntax language. C doesn't have generics, so there
| are several ways people have extended that base C-ish syntax to
| support generics: <>, [], template<>, and a few others have all
| been done in the past.
|
| https://en.wikipedia.org/wiki/Generic_programming - Worth
| studying up on if you're unfamiliar with it.
| Animats wrote:
| _" Longer term, we will build on this to introduce a safe Carbon
| subset. This will be a large and complex undertaking, and won't
| be in the 0.1 design."_
|
| If they can't get safety right at the design stage, they'll never
| get it right. We already have D and Zig in this space.
| pron wrote:
| Given that Carbon's space is "languages with full
| interoperability with C++," I don't think D and Zig are in that
| space.
|
| As to "getting it right" - things are not so simple. The
| emphasis on memory-safety soundness is based on some empirical
| hypotheses, some better founded than others, and it's unclear
| what "getting it right" means.
|
| From a software correctness perspective, the road to sound
| memory safety is as follows: 1. We want to reduce the amount of
| costly bugs in software as cheaply as possible, 2. Memory
| unsafe operations are a common cause of many costly bugs, 3.
| Some or all memory bugs can be eliminated cheaply with sound
| language guarantees.
|
| The problem is that 1. memory safety refers to several
| properties that don't all contribute equally to correctness
| (e.g. out-of-bounds access causes more serious bugs than use-
| after-free [1]), and 2. soundly guaranteeing different memory
| safety properties has different costs. It gets more complicated
| than that (e.g. there are also unsound techniques that have
| proven very effective to consider), but that's the overview.
|
| It is, therefore, as of yet unclear which memory safety
| properties are worth it to soundly guarantee in the language,
| and the answer may depend on the language's other goals (and
| there must be other goals that are at least as important,
| because the empty language guarantees not only all memory
| safety properties but _all_ (safety [2]) correctness
| properties, yet nobody uses it as it 's useless, while a
| language like ATS can be used to write many useful programs,
| but few use it because it's just too costly to use well). The
| goal is always to find the right balance.
|
| For example, Java soundly guarantees lack of use-after-free at
| the cost of increased memory footprint; that may be "getting it
| right" for some programs but not all. Rust soundly guarantees
| lack of use-after-free at the cost of imposing strong and
| elaborate typesystem constraints (that, as is often the case,
| are more constraining than the property they guarantee); that,
| too, may be "getting it right" for some programs, though not
| all. Zig guarantees lack of out-of-bounds access in a simple
| language at the cost of not guaranteeing lack of use-after-
| free, and that may also be "getting it right" for some programs
| but not all.
|
| So what "getting it right" means always depends on constraints
| _other_ than safety (Rust and Zig want to consume less memory
| than Java; Java and Zig want to be simpler than Rust; Java and
| Rust want to guarantee more memory safety properties than Zig).
| If Carbon wants to be more interoperable with C++ than Java,
| Rust, or Zig, then it will have to figure out what "getting it
| right" means _for Carbon_.
|
| [1]:
| https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html
|
| [2]:
| https://en.wikipedia.org/wiki/Safety_and_liveness_properties
| cjj_swe wrote:
| Splendid reply! I'm a big fan of Carbon and so I really
| appreciate when people make solid arguments for its tradeoff
| space.
| idispatch wrote:
| I counted the word "sound" in this reply 8 times. When I the
| word sound there is always the word Rust nearby. It is just a
| coincidence, of course.
| tylerhou wrote:
| Zig is nowhere near memory safe. Even some basic semantics
| (passing arguments as values or references) are horribly
| broken. https://github.com/ziglang/zig/issues/5973
| Imustaskforhelp wrote:
| Zig seems like a better approach but I still remember the carbon
| C killer video from fireship before that channel was bought by vc
| funding and turned into AI slop news reporter most likely using
| AI.
|
| I don't even watch fireship anymore. I actively resist the urge
| to. There are some other better channels like typecraft or
| primagen or dreams of code and so many other enthusiasts, there
| is this one bash guy that I watch whose having fun in life doing
| side quests like going to gym and gardening and I am all for that
| too.
| kjksf wrote:
| I think this page describes "what" but not "why" of Carbon.
|
| Carbon exists so that it's possible to migrate a large C++ code
| base, like Chrome, from C++ to something saner, incrementally.
|
| The most important attribute of Carbon is not the specifics of
| the syntax but the fact that it's designed to be used in a mixed
| C++ / Carbon code base and comes with tooling to convert as much
| of C++ as possible to Carbon.
|
| That's what makes Carbon different from any other language: D,
| Zig, Nim, Rust etc.
|
| It's not possible to port a millions line C++ code base, like
| Chrome, to another language so large C++ projects are stuck with
| objectively pretty bad language and are forced to continue to use
| C++ even though a better language might exist.
|
| That's why Carbon is designed for incremental adoption in large
| C++ projects: you can add Carbon code to existing C++ code and
| incrementally port C++ over to Carbon until only Carbon code
| exists.
|
| Still a very large investment but at least possible and not
| dissimilar to refactoring to adopt newer C++ features like e.g.
| replacing use of std::string with std::string_view.
|
| That's why it's a rational project for Google. Even though it's a
| large investment, it might pay off if they can write new software
| in Carbon instead of C++ and refactor old code into Carbon.
| cb321 wrote:
| Not to disagree, but to amplify - FWIW, most of what you say
| was also the sales pitch for C++ over ANSI C in the early 90s
| vs. the "pure Java" mentality that shortly followed in the late
| 90s (with a megaton of Sun Microsystems marketing to re-write
| almost everything rather than bridge with JNI). People neglect
| how practical incrementalism can be.
|
| Also, FWIW, it is very ergonomic for Nim to call C (though the
| reverse is made complex by GC'd types). { I believe similar can
| be said for other PLangs you mention, but I am not as sure. }
| It's barely an inconvenience. Parts of Nim's stdlib still use
| libc and many PLangs do that for at least system calls. You can
| also just convert C to Nim with the c2nim program, though
| usually that requires a lot of hand editing afterwards.
|
| Maybe they should write a C++2carbon translator tool? That
| would speed things up for them. Maybe they already have and I
| just haven't heard of it? I mean the article does say "some
| level of source-to-source translation", but I couldn't find
| details/caveats poking around for a few minutes.
| duped wrote:
| fwiw, many PLs find themselves needing to have C FFI if they
| want to support MacOS. It's not just a convenience thing.
| yegle wrote:
| A similar example is Facebook/Meta inventing Hack to
| progressively replacing the old PHP code.
| philwelch wrote:
| Zig is designed to interoperate like this with C, and Kotlin
| with Java.
| dang wrote:
| Related. Others?
|
| _Carbon is not a programming language (sort of)_ -
| https://news.ycombinator.com/item?id=42983733 - Feb 2025 (97
| comments)
|
| _Ask HN: How is the Carbon language going?_ -
| https://news.ycombinator.com/item?id=40480446 - May 2024 (1
| comment)
|
| _Will Carbon Replace C++?_ -
| https://news.ycombinator.com/item?id=34957215 - Feb 2023 (321
| comments)
|
| _Carbon Programming Language from Google_ -
| https://news.ycombinator.com/item?id=32250267 - July 2022 (1
| comment)
|
| _Google Launches Carbon, an Experimental Replacement for C++_ -
| https://news.ycombinator.com/item?id=32223270 - July 2022 (232
| comments)
|
| _Carbon Language: An experimental successor to C++_ -
| https://news.ycombinator.com/item?id=32151609 - July 2022 (504
| comments)
|
| _Carbon: high level programming language that compiles to plain
| C_ - https://news.ycombinator.com/item?id=4676789 - Oct 2012 (39
| comments)
| NooneAtAll3 wrote:
| I remember back when carbon first appeared, I immediately thought
| it's not gonna get popular simply because it has "fn" and "var"
|
| superficial details matter - people that stayed on C++ instead of
| transitioning to flashy new ones have type-before-name as part of
| programming identity
|
| you can have all the features in the world (and be recognized by
| it), but if the code doesn't _look_ like C++, then it's of no
| interest
| johannes1234321 wrote:
| Well, the Carbon team primarily focusses on one customer:
| Google. If management decides "it's carbon now" then a few
| thousand developers will write carbon or change jobs. If they
| are then somewhat successful inside Google, people leaving will
| spread it.
|
| I don't think it will reach the same distribution as other
| languages, as the niche is "large C++ projects, which want to
| transition to something else without rewrite" for anybody else
| there are a huge number of alternatives.
| z_open wrote:
| Are all major programming languages going to come from
| corporations in web 2.0?
| actionfromafar wrote:
| Web 2.0?
| can16358p wrote:
| Probably referring to "large tech companies that grew in the
| Web 2.0".
|
| Yeah, agree that it sounds slightly off initially.
___________________________________________________________________
(page generated 2025-07-31 23:00 UTC)