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.
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)
"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.
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
One could presumably compile arbitrary C++ to rust or D without changing semantics, then slowly go through the result making it look more native to the new language.
That would either be a wholesale conversion or emitting a translation shim style thing at the boundary between legacy c++ and the new language.
I'm not sure Carbon is necessary to achieve such a conversion.
How is it different from mere syntactic sugar over the same programming concepts? What does it bring that C++ cannot do?
Isn't it just a way of controlling the language vs using normative bodies?
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.
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.
Given the huge effort to make this language, I wonder if they could have directed that toward some kind of Rust-to-C++ bridge instead?
What's the pro of not having a stable ABI?
This language changes too much and too little all at the same time. It creates a burden on the developers without lifting many of the burdens of C++.
I can imagine the thought process behind the designers of the language went as follows:
"It's not possible to improve C++ without breaking backwards compatibility"
"That's correct, but if we're going to break backwards compatibility anyways, why not use this as an opportunity to change a bunch of things?"
aka the python 3 mentality, where necessary changes were combined with unnecessary changes that caused pointless migration costs. The fallacy is derived from the fact that breaking backwards compatibility is considered a massive fixed cost due to the fact that libraries have to be updated, therefore adding small incremental costs will not meaningfully increase overall cost. In reality the fixed cost of breaking backwards compatibility can be reduced massively if the proper care is taken, which means all the "just because" changes that were thrown in as a bonus, end up representing a much larger share of the migration cost than initially anticipated.
Are all major programming languages going to come from corporations in web 2.0?
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.
[2022]
[dead]
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.
Wow the syntax looks terrible.
in the end it's all bits in ram that a cpu has to execute. as long as the cpu ISA is build around common coding patterns found in c there seems no reason to use anything other than c. I get it that people do not like to code in a language that does not hold your hand. I myself prototype most of my code in c#. But in the end it has to fit inside the cpu ISA architecture.
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.