13 ms·

Carbon Language: An experimental successor to C++

155 points by samuell 1y ago

KingLancelot 1y ago
[dead]
bananapub 1y ago
[2022]
- Jtsummers 1y ago
  It's an ongoing project, specifying a date here wouldn't make much sense.
  - bananapub 1y ago
    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 1y ago
      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/docs/project/roadmap.md 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 https://youtu.be/8SGMy9ENGz8?si=reukeBjxAOivX6qI
    - Jtsummers 1y ago
      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 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 1y ago
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 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 1y ago
  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 1y ago
  > 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 1y ago
    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 1y ago
      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.
mihaic 1y ago
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 1y ago
  I kind of appreciate fn, personally. It's nice having function declaration lines with two less unnecessary characters in their length.
- flohofwoe 1y ago
  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 1y ago
    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 1y ago
    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 1y ago
    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.
darksaints 1y ago
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 1y ago
  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 1y ago
  The joke is that no* c++ dev actually likes the bracket syntax for templates. * I might be slightly exaggerating.
self_awareness 1y ago
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 1y ago
  `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 1y ago
    How is it inconsistent? The square brackets always mean "this was deduced" and the parens always indicate "this was passed in explicitly"
- cjj_swe 1y ago
  Square brackets do not indicate "this is a type". Instead they indicate "these things were deduced from their context"
- Jtsummers 1y ago
  [] 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 https://en.wikipedia.org/wiki/Generic_programming - Worth studying up on if you're unfamiliar with it.
Animats 1y ago
"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 1y ago
  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 https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html [2]: https://en.wikipedia.org/wiki/Safety_and_liveness_properties https://en.wikipedia.org/wiki/Safety_and_liveness_properties
Imustaskforhelp 1y ago
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 1y ago
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 1y ago
  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 1y ago
dang 1y ago
Related. Others? Carbon is not a programming language (sort of) - https://news.ycombinator.com/item?id=42983733 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 https://news.ycombinator.com/item?id=40480446 - May 2024 (1 comment) Will Carbon Replace C++? - https://news.ycombinator.com/item?id=34957215 https://news.ycombinator.com/item?id=34957215 - Feb 2023 (321 comments) Carbon Programming Language from Google - https://news.ycombinator.com/item?id=32250267 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 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 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 https://news.ycombinator.com/item?id=4676789 - Oct 2012 (39 comments)
NooneAtAll3 1y ago
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 1y ago
  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.
- Buttons840 1y ago
  Stockholm syndrome, after learning C++ syntax, surely it wasn't all for nothing, I can't accept that.
z_open 1y ago
Are all major programming languages going to come from corporations in web 2.0?
- actionfromafar 1y ago
  Web 2.0?
  - can16358p 1y ago
    Probably referring to "large tech companies that grew in the Web 2.0". Yeah, agree that it sounds slightly off initially.
- pjmlp 1y ago
  Where do you think even C and C++ came from?
JonChesterfield 1y ago
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.
- zem 1y ago
  I would be stunned if you could compile arbitrary c++ to rust or d, unless by "compile" you mean "painfully hand-translate and spend months fixing subtle errors". you are underestimating the sheer complexity of the language.
  - troad 1y ago
    Agreed, but it would be much worse than you suggest. Many meaty C++ projects have an underlying architecture that could not even be expressed in (safe) Rust. The idea of transpiling a major C++ project and getting it running in Rust with only some minimal idiom fiddling seems utterly fantastical.
  - JonChesterfield 1y ago
    Implementation would be by modifying clang. Traverse the clang ast emitting the new language instead of llvm IR. You wouldn't get idiomatic code out but with some effort you'd get rust/d/c/other which clang compiles to the same IR as the original. How much refactoring is warranted afterwards would depend on how much effort you put in to recreating templates / header files / modules etc on the fly. I'm not sure I'd choose to do this myself if I was in Google's position but it would be tempting.
    - zem 1y ago
      you would end up with llvm-ir-like code that was only technically rust/d insofar as the compilers could handle it. it would not be human-readable or maintainable at all; indeed, it would be harder to convert that to idiomatic rust/d than hand-translating the c++ code. and really, all you would gain would be getting rid of the c++ compiler and ending up with worse code. the point of carbon is that you can incrementally migrate your c++ program to it in place, and the migrated code will end up easier to maintain than the original c++.
uvas_pasas_per 1y ago
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?
- pzo 1y ago
  I think they had another such effort for a while here: https://github.com/google/crubit https://github.com/google/crubit
ygritte 1y ago
What's the pro of not having a stable ABI?
- Ygg2 1y ago
  Being able to change things. It's like all downsides of backwards compatibility but on a binary level As to things ABI prevents: - scoped_lock was added to not break ABI by modifying lock_guard - int128_t has never been standardized because modifying intmax_t is an ABI break. Although if you ask me, intmax_t should just be deprecated. - unique_ptr could fit in register with language modifications, which would be needed to make it zero-overhead, compared to a pointer - Many changes to error_code were rejected because they would break ABI - status_code raised ABI concerns - A proposal to add a filter to recursive_directory_iterator was rejected because it was an ABI break - A proposal to make most of <cstring> constexpr (including strlen) will probably die because it would be an ABI break. - Adding UTF-8 support to regex is an ABI break - Adding support for realloc or returning the allocated size is an ABI break for polymorphic allocators - Making destructors implicitly virtual in polymorphic classes - Return type of push_back could be improved with an ABI break - Improving shared_ptr would be an ABI break - [[no_unique_address]] could be inferred by the compiler should we not care at all about ABI Source: https://cor3ntin.github.io/posts/abi/ https://cor3ntin.github.io/posts/abi/
  - TuxSH 1y ago
    > Making destructors implicitly virtual in polymorphic classes Not sure what to think of this one. Either one introduces a new keyword to opt out (not great), or all public destructors of an abstract base class are implicitly marked virtual (not great and another "hidden" language feature like threadsafe-statics). After all, an abstract base class does not need its destructor to be public.
Surac 1y ago
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.
fooker 1y ago
Wow the syntax looks terrible.
benob 1y ago
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?
- cjj_swe 1y ago
  Well for one, in addition to templates it has definition checked generics. That alone justifies it to me, but it's far from the only improvement.
imtringued 1y ago
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.
verysorry42 1y ago
Chandler Carruth and his Carbon team might be both incompetent and dishonest. Is he and his team just scamming Google while working effectively without accountability, racking in money? How have they not gotten further? Why does the language seem so incompetently and carelessly designed? Do they put any effort or thought into it?

155 points by samuell 1y ago

KingLancelot 1y ago

[dead]

bananapub 1y ago

[2022]

Jtsummers 1y ago
It's an ongoing project, specifying a date here wouldn't make much sense.
- bananapub 1y ago
  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 1y ago
    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/docs/project/roadmap.md 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 https://youtu.be/8SGMy9ENGz8?si=reukeBjxAOivX6qI
  - Jtsummers 1y ago
    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 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 1y ago

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 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 1y ago
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 1y ago
> 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 1y ago
  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 1y ago
    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.

mihaic 1y ago

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 1y ago
I kind of appreciate fn, personally. It's nice having function declaration lines with two less unnecessary characters in their length.
flohofwoe 1y ago
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 1y ago
  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 1y ago
  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 1y ago
  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.

darksaints 1y ago

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 1y ago
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 1y ago
The joke is that no* c++ dev actually likes the bracket syntax for templates. * I might be slightly exaggerating.

self_awareness 1y ago

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 1y ago
`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 1y ago
  How is it inconsistent? The square brackets always mean "this was deduced" and the parens always indicate "this was passed in explicitly"
cjj_swe 1y ago
Square brackets do not indicate "this is a type". Instead they indicate "these things were deduced from their context"
Jtsummers 1y ago
[] 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 https://en.wikipedia.org/wiki/Generic_programming - Worth studying up on if you're unfamiliar with it.

Animats 1y ago

"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 1y ago
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 https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html [2]: https://en.wikipedia.org/wiki/Safety_and_liveness_properties https://en.wikipedia.org/wiki/Safety_and_liveness_properties

Imustaskforhelp 1y ago

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 1y ago

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 1y ago
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 1y ago

dang 1y ago

Related. Others? Carbon is not a programming language (sort of) - https://news.ycombinator.com/item?id=42983733 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 https://news.ycombinator.com/item?id=40480446 - May 2024 (1 comment) Will Carbon Replace C++? - https://news.ycombinator.com/item?id=34957215 https://news.ycombinator.com/item?id=34957215 - Feb 2023 (321 comments) Carbon Programming Language from Google - https://news.ycombinator.com/item?id=32250267 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 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 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 https://news.ycombinator.com/item?id=4676789 - Oct 2012 (39 comments)

NooneAtAll3 1y ago

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 1y ago
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.
Buttons840 1y ago
Stockholm syndrome, after learning C++ syntax, surely it wasn't all for nothing, I can't accept that.

z_open 1y ago

Are all major programming languages going to come from corporations in web 2.0?

actionfromafar 1y ago
Web 2.0?
- can16358p 1y ago
  Probably referring to "large tech companies that grew in the Web 2.0". Yeah, agree that it sounds slightly off initially.
pjmlp 1y ago
Where do you think even C and C++ came from?

JonChesterfield 1y ago

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.

zem 1y ago
I would be stunned if you could compile arbitrary c++ to rust or d, unless by "compile" you mean "painfully hand-translate and spend months fixing subtle errors". you are underestimating the sheer complexity of the language.
- troad 1y ago
  Agreed, but it would be much worse than you suggest. Many meaty C++ projects have an underlying architecture that could not even be expressed in (safe) Rust. The idea of transpiling a major C++ project and getting it running in Rust with only some minimal idiom fiddling seems utterly fantastical.
- JonChesterfield 1y ago
  Implementation would be by modifying clang. Traverse the clang ast emitting the new language instead of llvm IR. You wouldn't get idiomatic code out but with some effort you'd get rust/d/c/other which clang compiles to the same IR as the original. How much refactoring is warranted afterwards would depend on how much effort you put in to recreating templates / header files / modules etc on the fly. I'm not sure I'd choose to do this myself if I was in Google's position but it would be tempting.
  - zem 1y ago
    you would end up with llvm-ir-like code that was only technically rust/d insofar as the compilers could handle it. it would not be human-readable or maintainable at all; indeed, it would be harder to convert that to idiomatic rust/d than hand-translating the c++ code. and really, all you would gain would be getting rid of the c++ compiler and ending up with worse code. the point of carbon is that you can incrementally migrate your c++ program to it in place, and the migrated code will end up easier to maintain than the original c++.

uvas_pasas_per 1y ago

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?

pzo 1y ago
I think they had another such effort for a while here: https://github.com/google/crubit https://github.com/google/crubit

ygritte 1y ago

What's the pro of not having a stable ABI?

Ygg2 1y ago
Being able to change things. It's like all downsides of backwards compatibility but on a binary level As to things ABI prevents: - scoped_lock was added to not break ABI by modifying lock_guard - int128_t has never been standardized because modifying intmax_t is an ABI break. Although if you ask me, intmax_t should just be deprecated. - unique_ptr could fit in register with language modifications, which would be needed to make it zero-overhead, compared to a pointer - Many changes to error_code were rejected because they would break ABI - status_code raised ABI concerns - A proposal to add a filter to recursive_directory_iterator was rejected because it was an ABI break - A proposal to make most of <cstring> constexpr (including strlen) will probably die because it would be an ABI break. - Adding UTF-8 support to regex is an ABI break - Adding support for realloc or returning the allocated size is an ABI break for polymorphic allocators - Making destructors implicitly virtual in polymorphic classes - Return type of push_back could be improved with an ABI break - Improving shared_ptr would be an ABI break - [[no_unique_address]] could be inferred by the compiler should we not care at all about ABI Source: https://cor3ntin.github.io/posts/abi/ https://cor3ntin.github.io/posts/abi/
- TuxSH 1y ago
  > Making destructors implicitly virtual in polymorphic classes Not sure what to think of this one. Either one introduces a new keyword to opt out (not great), or all public destructors of an abstract base class are implicitly marked virtual (not great and another "hidden" language feature like threadsafe-statics). After all, an abstract base class does not need its destructor to be public.

Surac 1y ago

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.

fooker 1y ago

Wow the syntax looks terrible.

benob 1y ago

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?

cjj_swe 1y ago
Well for one, in addition to templates it has definition checked generics. That alone justifies it to me, but it's far from the only improvement.

imtringued 1y ago

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.

verysorry42 1y ago

Chandler Carruth and his Carbon team might be both incompetent and dishonest. Is he and his team just scamming Google while working effectively without accountability, racking in money? How have they not gotten further? Why does the language seem so incompetently and carelessly designed? Do they put any effort or thought into it?