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.
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.
Nim 2 doesn’t require gc, with arc/atomicArc. The only thing you really need to be careful about is when you use ref types or custom owning types. Otherwise, manual memory management can be done in Nim pretty easily.
Hypothetically you could importcpp fns, classes, etc when compiling with nim cpp
We have zero disagreement here (actually true of all responses to my comment - an odd circumstance on HN). What you call "`ref` types" is what I meant by "GC'd types". I actually like that the Nim compiler changed from `--gc=X` to `--mm=X` a while back as the key distinction is (& has always been) "automatic vs. manual".
Elaborating on this cross-talk, any academic taxonomy says reference counting is a kind of GC. { See, the subtitle or table of contents of Jones 1996 "Garbage Collection: Algorithms for Automatic Dynamic Memory Management", for example. } Maybe you & I (or Nim's --mm?) can personally get the abbreviation "AMM" to catch on? I doubt it, but we can hope!! :) Sometimes I think I should try more. Other times I give up.
Before the late 90s, people would say "tracing GC" or "reference counting GC" and just "GC" for the general idea, but somehow early JavaVM GC's (and their imitators) were so annoying to so many that "The GC" came to usually refer, not just to the abstract idea of AMM, but to the specific, concrete separate tracing GC thread(s). It's a bit like if "hash table" had come to mean only a "separately chained linked list" variant because that's what you need for delete-in-the-middle-of-iterating like C++ STL wants and then only even the specific STL realization to boot { only luckily that didn't happen }.
The open addressed hash tables basically don't exist for a long time. The various strategies for collision handling in these tables are from the 1980s or later and if you don't have a collision strategy you can't use this as a general purpose container. I'm pretty sure I never used a hash table which didn't use separate chaining until at least the 1990s and perhaps later.
So that's maybe a bad example. In the same way I think it's fine that "Structured programming" is about the need to use structured control flow, not the much later idea of structured concurrency even though taken today you might say they both have equal claim to this word "structured".
In contrast it is weird that people decided somehow "Object oriented" means the features Java has, rather than most of what OO was actually about when it was invented. I instinctively want to blame Bjarne Stroustrup but can't think of any evidence.
I can't speak to what libraries you used, but both techniques have been broadly used in common practice since the 1950s. According to the "History" subsection in Knuth TAOCP v3 at the very end of 6.4 (whose very first edition written in 1972 covered OA with various probe/collision strategy ideas), both open addressing & separate chaining were co-invented at IBM in 1953/54 by Luhn & Amdahl. You may be confusing the Celis 1985 Robin Hood hashing work with just the open addressing part? Anyway, as you say, it may be a strained example/analogy. "OO" & "concurrency" both have a lot going on, too.
Anyway, like the "major" modes of hash collision resolution, reference counted GC has also been around concurrently (haha) with ref tracing GC since the dawn of modern computing. Unix hard-links (& other things) codify ref counting into filesystems.. Python has always had ref-counted GC, older Lisp more focused on tracing GC, etc., etc. Popularity measures are notoriously difficult.
Mostly people like to abbreviate { like having a search $PATH instead of using /bin/foo everywhere }. The whole point of abstraction is to neglect details. Neglect naturally leads to forgetting (or never learning/knowing). Ignorance leads people to cross-talk (or worse willfully misinterpret/project). Cross-talk leads to suffering. Yoda out. ;-)
EDIT: Also, speaking of abbreviation & clarity, in Nim "arc" has, at least until this writing, always stood for Automatic Reference Counting, not Atomic Ref Counting as seems the more rusty terminology and is vaguely suggested by @miguel_martin, to whom I originally replied with an "arc/atomicArc", though it seems like, in Nim 3, it may become both Automatic & Atomic, but probably not changing its abbreviation to "AARC".
None of the schemes I was aware of pre-date Celis in 1985 but it's apparent upon actually reading Celis [which I hadn't done previously] that he's only improving on an existing state of the art, so I was entirely wrong about that. That state of the art was pretty dire by my reckoning, but it's clear that it would have worked so I was entirely wrong and I apologise for being so assertive when in fact I clearly didn't know what I was talking about.
I see. So, it's just a slide-ware bullet point right now? It would be helpful to really emphasize a word like "planned" in that bullet. It might have been lifted from some future-sounding/plan-oriented list and now the material makes it seem like it's actually available.
The nightly release of the Carbon compiler can be used via https://carbon.compiler-explorer.com/ . Note that it is definitely a work in progress, it hasn't even reached our v0.1 goals yet, but a good chunk of important functionality is working.
But couldn’t one argue that’s true of most languages, they promise incremental progress toward rewriting your behemoth into miniature monoliths? I think the only one where they clearly drew the line at being able to pull in headers is .Net. You just can’t do it. Others like Golang or rust, you can point to the C headers and bam…
Honestly, while I find the syntax terse, I welcome more low level languages able to push performance.
These are strong points and I think the methodology behind Carbon is the correct one. The elephant in the room is that once Google decide to drop Carbon my existing code base will be dependant on a dead technology and then I am screwed.
I find it hard to trust Google to maintain any software nor to write software that is maintainable by a community. They write software for themselves and themselves alone.
If it (purportedly?) exists so that Google can move multi-million line code bases from C++ to something better bit-by-bit, because it's otherwise infeasible to do so, why would Google drop it after they have ported the first million?
You could do this with Nim, Nim 2’s ARC model is compatible with c++’s RAII. Nim supports moves, destructors, copies, etc. see https://nim-lang.org/docs/destructors.html
You can import C++ classes, member functions, free functions, etc. easily with importcpp
importcpp for the code you are incrementally porting over. You could write a libclang script to do this for you. Exportcpp for what you any code that have been ported but have dependencies in C++ land.
My best guess is they want C++ compatibility and a new language due to preferences, more control over the compiler, etc. which are all valid reasons
What I would like to see is more documentation on the "why not" that summarizes why other languages and proposals are not sufficient. For example, Safe C++ proposal[1] appears to satisfy all requirements, but I can't find any reference to it.
The reason the Safe C++ proposal wasn't mentioned is that it came years later. =] I'll see if it makes sense for us to update that section a bit, this probably isn't the only thing that we should refresh a bit to reflect the last few years of developments.
FWIW, the biggest challenge with Safe C++ is that WG21 rejected[1] that direction. And it was developed without building a governance model or way to evolve outside of WG21, and so doesn't seem to have a credible path forward.
[1]: FWIW, some members of WG21 don't agree with this characterizationp, but both the author's impression and the practical effect was to reject the direction.
To your footnote, this has been a constant refrain from WG21. One of the biggest achievements from yourself and many others was getting WG21 to explicitly reject P2137 the "Goals and priorities" paper rather than dithering and refusing to commit as happened for "Safe C++" and for the ABI paper.
I believe that getting WG21 to actually say "No" was very useful to have non-technical leadership people understand that C++ can't be the solution they need.
Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation? Circle, as far as I know, is closed-source.
> Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation?
Technically speaking the clauses on either side of the "or" aren't mutually exclusive. You can have a "full, correct, fully compliant, reference implementation" that is also a closed-source implementation!
Well, unless the implication that Circle isn't "full, correct, [and] fully compliant", in which case I feel I should ask "with respect to what?" and "why do you need those requirements?"
But Safe C++ and Circle are different languages, right? And Circle is not the same as the Safe C++ proposal that was submitted, right? There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere. I cannot find any occurrences of "reference implementation" in the Safe C++ draft.
> But Safe C++ and Circle are different languages, right?
Eh, bit of a mixed bag, I think, depending on the context in which the words are used. "Circle" can refer to the compiler/toolchain or the set of C++ extensions the compiler implements, whereas Safe C++ is either the proposal or the extensions the proposal describe. As a result, you can say that you can compile Safe C++ using Circle, and you can also describe Safe C++ as a subset of the Circle extensions. I wouldn't exactly describe the lines as well-defined, for what it's worth.
> There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere.
They're sort of documented indirectly, as far as I can tell. Compare the features in the Safe C++ proposal and the features described in the Circle readme [0]. That'll get you an approximation at least, albeit somewhat shaded by the old docs (understandable given the one-man show).
> I cannot find any occurrences of "reference implementation" in the Safe C++ draft.
The exact words "reference implementation" may not show up, but I think this bit qualifies (emphasis added):
> Everything in this proposal took about 18 months to design and implement in Circle.
If they're the same language, then I think it's a fair objection that it's closed-source, as some people might find using a closed-source compiler to be unsuitable as a replacement for the existing open source C++ ones. If it's not the same language, then it's not clear that Safe C++ actually exists today, so it also seems fair that people might be interested in alternatives that they expect might be available sooner.
I don't think the objection in the first sentence makes sense because I don't think replacing the existing C++ compilers was ever in the cards. If anything, the fact that the Safe C++ proposal has a section titled "Implementation Guidance" seems to point to precisely the opposite - that the intent was for existing C++ compilers to be updated to add the new features, not that Circle was to replace them.
I'm not sure about the second sentence either? Circle (supposedly?) implements everything in the Safe C++ proposal, so in that respect Safe C++ exists. Alternatively, you can say Safe C++ doesn't exist because major compilers don't implement it, but that's kind of the point of the Safe C++ proposal (and many (most?) other C++ language proposals, for that matter) - it's describing new features that don't currently exist but might be worth adding to the standard.
> people might be interested in alternatives that they expect might be available sooner.
This is also a bit funny because this was one of the more contentious points of debate in the Safe C++ vs. profiles discussion, and the impression I got is that between the two Safe C++ was generally considered to be closer to "might be available sooner" than profiles.
It sounds like the difference of opinion here is around how soon we expect that the major compilers will actually implement the safe features. I tend not to be optimistic that these sorts of changes will be available anytime soon, and I think it would be fair to consider alternatives at this point, but that's obviously a judgment call and not everyone will agree on that.
As far as Safe C++ vs. profiles specifically, I don't think the conversation really ever got to the point of serious discussions of how soon the features could be implemented. My understanding is that there were bigger hangups about what direction to go in the first place as well as what "profiles" even meant.
> and I think it would be fair to consider alternatives at this point
I would assume those who could consider alternatives already have, and that those (still) interested in safe(r) C++ do so because the alternatives are insufficient for one reason or another.
But standardization also matters for avoiding vendor lock-in, right?
Like, Python and Javascript both have many "implementations", and those are some of the most popular languages. Python does not have an ISO specification. But Javascript does have an Ecma standard, ECMAScript.
> Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally.
_Incrementally_: a C++ project can be incrementally made more sane also using constructs to avoid and constructs to use once the problem domain is confined. In my past, I had successfully implemented this quest for 3 different fairly large C++ projects. This is not a strong selling point for carbon.
i always emphasize to new programmers to learn any language and practice it with respect and discipline. All languages have dark corners, the human who can reason which constructs are appropriate.
Once you've done this work though, what stops the codebase from slowly drifting back into the less sane realm it previously resided in? It seems pretty reasonable to be concerned that a company that produced a messy codebase once is capable of making it messy again, and given that turnover is inevitable in the long term (which is the timeframe that seems relevant given that long-term compatibility in C++ codebases is kind of the whole reason this discussion is happening), it doesn't seem like relying on an individual to enforce the rules is super viable. The obvious way to enforce this sort of thing is through tooling, and there's no tool more powerful than literally making it impossible to express the undesirable code in the language itself in the first place.
You're right that incrementally rewriting isn't much of an advantage over C++ itself, but I think you're missing the point that the emphasis on "incremental" is to highlight the advantage in rewriting C++ code in Carbon over alternatives that don't provide as much compatibility (with Rust being somewhat notorious for being suggested by outside parties as a target for rewriting in whenever discussions about C++ codebases happen). The argument for Carbon over C++ isn't specifically that it can be rewritten incrementally, but that it's just a better language, which has benefits _after_ the rewrite. To be clear, I'm sure that someone could come up with reasonable objections to that claim as well, but I think it's distinct from the part you're objecting to, and it's worth treating as a separate concern.
It's a great feature, and D has a bunch of support for this kind of thing.
But D and C++ have just enough differences to make extern(C++) not be automatic. It can take some pretty arcane metaprogramming to get things to work, and some things are impossible.
It's also worth pointing out that D isn't trying to be fully compatible with C++.
I really struggle to imagine an organisation that shepherds a large and venerable C++ codebase migrating over to Swift.
For all of C++'s faults, it is an extremely stable and vendor-independent language. The kind of organisation that's running on some C++ monolith from 1995 is not going to voluntarily let Apple become a massive business risk in return for marginally nicer DX.
(Yes, Swift is OSS now, but Apple pays the bills and sets the direction, and no one is seriously going to maintain a fork.)
Do you have projects with huge code bases of Obj-C++ in mind?
I guess, some Mac apps? In that case I think most platform independent "guts" would be in C or C++, and the Obj-C++ part is tied to the frameworks, so the devs would have to rewrite it anyway.
The real "why" is because, unlike other languages, Google can't strong-arm or bribe C++'s ISO committee into doing its bidding, and that has caused problems for Google in the past. Carbon is a language born out of a corporate hissy fit.
Depends on how much people one sends to WG21 voting sessions, some folks at Reddit would assert contracts only got into C++26, thanks to Bloomberg votes.
In which way is C++ an "objectively pretty bad language"?
I have done C++ for a living and it is not the easiest but there is tooling and warnings as errors that catch a lot of the errors before even you make a mistake.
It is true that packaging is more challenging but it is also true that it is very configurable ro squeeze performance as much as possible (which is on of C++'s niches). And by squeezing I mean beyond setting a release build. You could for example decide to go with LTO + PGO + remove position independent code and do static linking for all dependencies, for example.
You can do virtually anything that no other language can do and whwn you need it, believe me it is useful.
But you can still code every day code wirh your lambdas, ranges, smart pointers and virtual interfaces.
I understand C++ has some baggage but is is very far from being an "objectively bad language" in ly opinion. More so if you take into account its performance and library availability, which is second to none for almost any task, except maybe for the typical enterprise-like Java app or web stuff, byt niw C++26 will include reflection and annotations, so this could be a game changer.
Explicitly and between the lines, Carruth and Google have made it clear that the “bad” part of C++ from their perspective is the standards committee.
In particular, the committee’s unwillingness to make ABI-breaking changes to the language, or more abstractly, to consider the needs of organizations with huge active code bases at least as seriously as those with huge legacy code bases.
Maybe a hybrid approach should be done byt breaking ABI in a so Core-supported language can cascade into so many places.
People say that Rust is great bc of that but that is just a trade-off and anyway there are olenty of dependencies like Boost, Abseil or others that can play that role anyways
One other use case I could think of is gaming, where there is an incredible amount of load-bearing C++ code that's never realistically going to be rewritten, and strict memory safety is not necessarily a sine qua non in the way it is in other fields.
> 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.
One good aspect about C++ is its backwards compatibility or stability. Also a drawback, but companies not having to spend huge amounts of time, expertise and money rewriting their whole codebases all the time is something they appreciate.
Might worth noting that this change technically doesn't violate Rust's stability guarantees since type inference changes and/or adding new impls are exempt. Of course, that doesn't really help with the question of whether this change should have been made in the given timeframe (as opposed to the socket struct change IIRC?), but that ship has long sailed.
They could be amended, but I suspect they will not be. There's a reason those exemptions were added in the first place, and the impression I get is that the 1.80 issues were more of a social problem that doesn't significantly change the reasons the exemptions were added in the first place.
In addition, as I mentioned I don't think this is the first time Rust has had to navigate this kind of wide-ranging technically-allowed-but-still-breaking change. The Rust devs first created a PR to change its internal representation for IP addresses in November 2020 [0], but multiple major libraries (including mio, which tokio depends on) incorrectly assumed that the representation for Rust's IP address type was the same as libc's representation and basically type punned between the two, so the change would result in UB. The Rust devs could have pushed out the change anyways, as the change didn't violate the backwards compatibility guarantee due to just being an internal implementation detail change, but the PR didn't actually land until July 2022 [1] because the Rust devs wanted to give the ecosystem time to migrate.
Yes, this was a social issue more than a technical one.
At the same time, I was affected by this breakage, and it took me all of ten minutes to fix. So I both understand the outrage, and agree with it in general, but also, it was a tad overblown, I think.
Should they have done a slower rollout, like the IpAddr change? Probably. Is it the end of the world that they made a mistake? Nah. But if it happens more often, that's cause for concern.
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.
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.
> 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.
FWIW, we're working hard whenever looking at an aspect of the language to look at other languages beyond C++ and learn any and everything we can from them. Lots of our design proposals cite Swift, Rust, Go, TypeScript, Python, Kotlin, C#, Java, and even Scala.
Make sure you're checking out Hylo. I'm not sure that its ideas are right for Carbon, but if you're looking for a credible alternative to Rust's take on safety, I think it's one of the better ones.
Chandler I would love to be involved in Carbon development to shape its development to be usable at my company or alternatively to use it in my own projects. What is the best way to stay involved in Carbon development? Just the discord?
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.
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.
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.
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.
C++ 26 doesn't have the technology, but it wouldn't matter anyway because what's crucial about Rust isn't the technology it's the culture.
If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does.
Beyond that though, the profiles idea is dead in the water because it doesn't deliver composition. Rust's safety composes. Jim's safe Activity crate, Sarah's safe Animals crate and Dave's safe Networking crate compose to let me work with a safe IPv6-capable juggling donkey even though Jim, Sarah and Save have never met and had no idea I would try that.
A hypothetical C++ 29 type safe Activity module, combined with a thread safe Animals module, and a resource leak safe Networking module doesn't even get you something that will definitely work, let alone deliver any particular safety.
> If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does.
I'm sure you think this was somehow succinctly making your point, but I can't see any connection at all, so if you did have an actual point you're going to need to explain it.
OK? I don't see how that's connected? It's not controversial that f32 and f64 are partially ordered, the problem in C++ is that the difference between "Partially Ordered" and "Totally Ordered" is semantic not syntactic in their language and all semantic mistakes are just IFNDR so it's a footgun.
Some part of it want C++ to be Rust, with a focus on compile-time safety. Others take "C++" literally as "C with extra stuff" and value performance over safety.
Companies like Google are likely to be in the former camp, as for what they are doing, security is critical. Unsurprisingly, Carbon is a Google project.
Video game companies on the other hand are likely to be in the latter camp. Most of the times, security is not as critical, especially for offline games, and memory corruption usually don't go further than a game crash. Tight memory management however is critical, and it often involves raw pointers and custom allocation schemes.
I blame the "we won't recompile anything ever" stance from the financial organisations for the breakdown. It means C++ cannot fix mistakes, even when they harm performance, under the general name of "abi stability".
Thus there is an opening for a faster language. And still for a safer one. And for an easier one to use. So all C++ has going for it is inertia. It's moribund unless the committee reconsider their stance on intentionally losing the performance competition.
I remember reading that google tried to impress on WG21 and 14 the need to update the ABI and they were utterly opposed. The result is google is no longer interested in C++. Apple I think is also no longer interested in C++. I think also Swift now has a stable ABI.
It's implied if you know, but Corentin's post doesn't actually link Titus's C++ proposal P1863 "ABI: Now or Never" which is what we're most concretely talking about here.
Titus correctly predicts the committee's actual response and highlights its danger, summarised in the title. You can pick now, as Corentin desires. You can pick never, which Corentin despairs at - not unreasonably because it means you're giving up performance. But Titus highlights the third option, the committee can instead dither forever never having the courage to announce an ABI break but also lacking courage to declare absolute stability with the encouragement that brings for legacy systems.
ABI Now is - at least in performance - competing with Rust. An ABI swap can make some C++ have the same performance as the analogous Rust which wasn't possible with the old ABI and that matters for outfits like Google.
ABI Never is a different niche. Guaranteed ABI stability gives C++ certainty. It makes C++ a stronger contender for some applications where today it can't go and nor can Rust because people don't think "Just recompile" is a reasonable choice, whether they are correct or not.
ABI Dither is neither of these things. There is no certainty, just because the committee is dithering today doesn't mean they won't make a decision tomorrow, or next year. But meanwhile you're not competitive with the best in class alternatives
Carbon is performance-first, so ABI instability is the default. We plan to have opt-in ABI stability, but that story is not well developed yet. Replacing C as the lingua franca is not a goal, at least not yet.
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.
This is a cool project, but it doesn’t address my original issue with Zig, which is that the language’s semantics is not even specified. That is, we cannot define what a “memory safe Zig program is” as we cannot even define what a Zig program is! (Unless you define the semantics of a Zig program in terms of the implementation/translation to IR, which is fragile / bad.)
Second, I would be surprised if the static analyses in the tool are precise enough for real-world Zig programs. For example, it is undecidable to determine whether a function “takes ownership” of an argument pointer. In particular, if you want to avoid false negatives, the “free after transfer” case needs to be conservative, but then you almost certainly will flag false positives.
of course. There will absolutely need to be a way to specify intent in certain cases or override the judgement of the checker. That may come in the form of external annotation, or possibly internal annotation, which in principle is achievable using the same technique as you see in the "unitful" demo, though that's not ideal.
as for zig being specified, well, it's pre 1.0, and the authors have I believe, specifically called out specification as being "the first priority after 1.0".
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.
> 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.
It means eliminating undefined behavior, and unplanned interaction between distant parts of the program.
Eliminating undefined behaviour is a means to an end (reduces problematic bugs, but not all undefined behaviour is equally responsible to such bugs), and it's not a binary thing (virtually all programs need to interact with software written in languages that don't eliminate undefined behaviour, so clearly there's tolerance to the possibility of undefined behaviour).
Don't get me wrong - less undefined behaviour is better, but drawing a binary line between some and none makes for a convenient talking point, but isn't necessarily the sweet spot for the complicated and context-dependent series of tradeoffs that is software correctness.
By definition all the C++ Undefined Behaviour is unbounded. You may believe, and even you may have practical evidence for the compilers which happen to exist today, that in some cases the behaviour in fact bounded, but that's not what the language definition says and optimisers have a funny way of making fools of people who mistake Undefined for "Eh, it'll probably do what I meant".
It might seem as though incrementing a signed integer past its maximum can't be as problematic as a use after free even though both are Undefined Behaviour, but nah, in practice in real C++ compilers today they can both result in remote code execution.
There is a place for Unspecified results, for example having it be unspecified whether a particular arithmetic operation rounds up or down may loosen things up enough that much faster machine code is generated and well, the numbers are broadly correct still. But that's not what Undefined behaviour does.
Yes, that's what UB means - the program loses all meaning and any effect is possible - but the importance of a bug is much more than just its blast radius. We ultimately care not about the language semantics of a bug but its expected loss of value. This is also dependent on how frequently the bug appears and how easy it is to prevent or find and fix. Not all UBs are equal on that front.
Furthermore, an unbounded blast radius isn't itself the direct problem. A bug that with some probability casues your program to crash and your disk to be deleted is far less dangerous than a bug that allows a remote attacker to relatively easily steal all your secrets. UBs also differ on that front.
And again, virtually all programs are not provably without UB. For example, a Java program still interacts with an OS or with some native library that might suffer from a UB. So clearly we do tolerate some probability of UB, and we clearly do not think that eliminating any possibility of UB is worth any price.
When a program is just code on the screen, it's just a mathematical object, and then it's easy to describe a UB - the loss of all program meaning - as the most catastrophic outcome. But software correctness goes beyond the relatively simple world of programming language semantics, and has to consider what happens when a program is running, at which point it is no longer a mathematical object but a physical one. If a remote attacker steals all our secrets, we don't care if it's a result of some bug in the program itself (due to UB or otherwise), in other software the program interacts with, some fault or weakness in the hardware, or human operator error. The probability of any of these things is never zero, and we have to balance the cost of addressing each of these possibilities.
To give an example in the context of Carbon, we know that old code tends to suffer from fewer severe bugs than new code. So, if we want to reduce the probability of bugs, it is possible that it may be more worthwhile to invest - say, in terms of language complexity budget - in interop with C++ code than in eliminating every possible kind of UB, including those that are less likely to appear, sneak past testing, and cause an easily exploitable vulnerability.
Nah, this is in the context of C++ so UB isn't the most catastrophic situation. Undefined Behaviour is a behaviour, which means we might well be able to avoid invoking the behaviour and then it's fine. For example if your C++ program has a use-after-free in the code invoked only by the "Add file" feature but otherwise works fine, we can just ensure operators never use "Add file" and the UB, no matter what it might be, won't happen.
C++ has IFNDR, clauses which say this is "Ill-Formed, No Diagnostic Required". The program itself wasn't actually a valid C++ program, it has absolutely no defined meaning, there may be no indication of a problem from your compiler but alas it's entirely meaningless. This isn't behavioural, it's an invisible status of the entire program.
As I said, UB means that a program has no meaning in the source language. That doesn't change anything I wrote above about the impact of UB. A hardware fault may also make a program meaningless, BTW, yet we all accept that every program written in any language is currently susceptible to UB or to a hardware fault.
If you want, you can think of UB like a mathematical singularity in some physical theory. The theory of the language has nothing to say about what happens in such a program. But that doesn't mean that we can't reasonably talk about what happens not using that theory [1]. Indeed, one of the reasons that UB are of concern is that some of them are frequent causes of security exploits - and that's the thing we ultimately care about, not that the program loses its semantics. But again, not all of them are equally common causes of such outcomes, and not all of them are equally hard to avoid in the first place.
[1]: In fact, this is easy to explain in software: the programming language can say nothing about the meaning of a program with UB - indeed, it has no meaning in that language - but because we do have an executable, the program still has a well-defined meaning in the machine language it compiled to (machine language has no UB, or, even if some machine architecture does declare that some instruction stream is UB, most programs with UB in some programming language still do not compile to a program with UB in machine code). So the program that has no meaning in C++ still has meaning in machine code, and as that is the program we ultimately run and care about, we can talk about which UBs are more or less likely to result in which machine code behaviour.
UB is a behaviour, it's unbounded, so it's an immediate disaster, and "time travel" UB can make this harder to reason about, because the as-if rule can mean that although it didn't in some sense "happen" yet the behaviour has consequences earlier. But if we avert the behaviour it won't happen. It is not correct to say that UB means the entire program had no meaning.
You give the "mathematical singularity" analogy, consider division. We doubtless agree than 6 divided by 3 is 2. And 6 divided by 2 is 3. But how about 6 divided by 0? This is not defined, we cannot perform such an operation. But division is not as a result somehow entirely without meaning, it just has this well understood limitation. Likewise for software with UB that we can avert.
IFNDR is a catastrophe because it truly does render the entire software without meaning.
> IFNDR is a catastrophe because it truly does render the entire software without meaning.
In the language. I.e. the language assigns no meaning to source the program, which is, indeed, the "catastrophic" impact of UB (or IFNDR) within the theory of the language. But since a running program takes the form of an executable, and the executable always has a defined meaning in another language (machine code), while C++ has nothing to say about what such programs do (i.e. that's the end of the helpfulness of that theory) that doesn't mean we can't talk about or care about the meaning of the executable.
An executable that crashes and an executable that leaks all your secrets have very different consequences, and while the C++ spec says absolutely nothing about the relationship between different UBs and these behaviours, that doesn't mean that these relationships don't exist.
A mathematical singularity in a physical theory means that that particular theory has nothing to say about the physics of that situation, not that there's no actual physics going on, and the physics that is actually going on could be more or less "catastrophic" depending on what we mean by that.
To be more concrete, event though two programs can both be meaningless in C++, i.e. C++ says nothing about what they actually do once compiled and run, we can sometimes say that one of them is much more likely to lead to a security exploit than the other. This is even used in practice in techniques such as this one: https://www.cl.cam.ac.uk/~tmj32/papers/docs/ainsworth20-sp.p...
It keeps adding keywords and it has become way harder to keep it in your head. It’s over 220 at this point. Don’t take my word for it, Swift creator doesn’t agree with its current direction either.
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
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.
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.
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.
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.
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.
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.
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++.
This was essentially how DMD (the reference D compiler) was translated to D.
However this was mostly a restricted subset of C++ common to both of them, e.g. no diamond inheritance, no operator overloading whackiness.
[] 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.
`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.
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.
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.)
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.
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?
> 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.
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].
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.
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.
0 vs 1 indexing has an actual semantic difference that you have to keep in your head at ~all times, but could have a text editor plugin that rewrites func<->fn since it's purely syntactical.
"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?
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.
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).
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.
I have that and still prefer class, easier to type(not just shorter, but easier keys) and less to read.
Only use typename in the rare case where it is required
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.
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.
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.
function add(a: i32, b: i32): i32 {
return a + b;
}
Than the example you provided and it is approximately the same length. I used to arrow functions everywhere in TS/JS and it made it difficult to read IME, and there was zero benefit. They are find for things like event handlers, promises chains etc. But I'd rather just use function when I don't have to worry about the value of this.
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?
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.
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.
Nim 2 doesn’t require gc, with arc/atomicArc. The only thing you really need to be careful about is when you use ref types or custom owning types. Otherwise, manual memory management can be done in Nim pretty easily.
Hypothetically you could importcpp fns, classes, etc when compiling with nim cpp
We have zero disagreement here (actually true of all responses to my comment - an odd circumstance on HN). What you call "`ref` types" is what I meant by "GC'd types". I actually like that the Nim compiler changed from `--gc=X` to `--mm=X` a while back as the key distinction is (& has always been) "automatic vs. manual".
Elaborating on this cross-talk, any academic taxonomy says reference counting is a kind of GC. { See, the subtitle or table of contents of Jones 1996 "Garbage Collection: Algorithms for Automatic Dynamic Memory Management", for example. } Maybe you & I (or Nim's --mm?) can personally get the abbreviation "AMM" to catch on? I doubt it, but we can hope!! :) Sometimes I think I should try more. Other times I give up.
Before the late 90s, people would say "tracing GC" or "reference counting GC" and just "GC" for the general idea, but somehow early JavaVM GC's (and their imitators) were so annoying to so many that "The GC" came to usually refer, not just to the abstract idea of AMM, but to the specific, concrete separate tracing GC thread(s). It's a bit like if "hash table" had come to mean only a "separately chained linked list" variant because that's what you need for delete-in-the-middle-of-iterating like C++ STL wants and then only even the specific STL realization to boot { only luckily that didn't happen }.
The open addressed hash tables basically don't exist for a long time. The various strategies for collision handling in these tables are from the 1980s or later and if you don't have a collision strategy you can't use this as a general purpose container. I'm pretty sure I never used a hash table which didn't use separate chaining until at least the 1990s and perhaps later.
So that's maybe a bad example. In the same way I think it's fine that "Structured programming" is about the need to use structured control flow, not the much later idea of structured concurrency even though taken today you might say they both have equal claim to this word "structured".
In contrast it is weird that people decided somehow "Object oriented" means the features Java has, rather than most of what OO was actually about when it was invented. I instinctively want to blame Bjarne Stroustrup but can't think of any evidence.
I can't speak to what libraries you used, but both techniques have been broadly used in common practice since the 1950s. According to the "History" subsection in Knuth TAOCP v3 at the very end of 6.4 (whose very first edition written in 1972 covered OA with various probe/collision strategy ideas), both open addressing & separate chaining were co-invented at IBM in 1953/54 by Luhn & Amdahl. You may be confusing the Celis 1985 Robin Hood hashing work with just the open addressing part? Anyway, as you say, it may be a strained example/analogy. "OO" & "concurrency" both have a lot going on, too.
Anyway, like the "major" modes of hash collision resolution, reference counted GC has also been around concurrently (haha) with ref tracing GC since the dawn of modern computing. Unix hard-links (& other things) codify ref counting into filesystems.. Python has always had ref-counted GC, older Lisp more focused on tracing GC, etc., etc. Popularity measures are notoriously difficult.
Mostly people like to abbreviate { like having a search $PATH instead of using /bin/foo everywhere }. The whole point of abstraction is to neglect details. Neglect naturally leads to forgetting (or never learning/knowing). Ignorance leads people to cross-talk (or worse willfully misinterpret/project). Cross-talk leads to suffering. Yoda out. ;-)
EDIT: Also, speaking of abbreviation & clarity, in Nim "arc" has, at least until this writing, always stood for Automatic Reference Counting, not Atomic Ref Counting as seems the more rusty terminology and is vaguely suggested by @miguel_martin, to whom I originally replied with an "arc/atomicArc", though it seems like, in Nim 3, it may become both Automatic & Atomic, but probably not changing its abbreviation to "AARC".
None of the schemes I was aware of pre-date Celis in 1985 but it's apparent upon actually reading Celis [which I hadn't done previously] that he's only improving on an existing state of the art, so I was entirely wrong about that. That state of the art was pretty dire by my reckoning, but it's clear that it would have worked so I was entirely wrong and I apologise for being so assertive when in fact I clearly didn't know what I was talking about.
Source-to-source translation is definitely planned. We've even done some early experiments.
But we need to get the language and interop into good shape to be able to thoroughly test and evaluate the migration.
I am trying to run Carbon in Godbolt.
Printing as in the example from Carbon's Github repository, does not work. 'Print("Test");' gives a complaint about not finding 'Print'.
That is correct. Strings and I/O both have a bunch of work to be done. Printing currently requires workarounds like https://godbolt.org/z/MP4164f7s
Array iteration got checked into the prelude so this is now shorter: https://godbolt.org/z/YYheo19ea
I see. So, it's just a slide-ware bullet point right now? It would be helpful to really emphasize a word like "planned" in that bullet. It might have been lifted from some future-sounding/plan-oriented list and now the material makes it seem like it's actually available.
Is there a compiler, maybe an online one, for Carbon, or some way to compile and run Carbon code? And if not, what are the plans for that?
The nightly release of the Carbon compiler can be used via https://carbon.compiler-explorer.com/ . Note that it is definitely a work in progress, it hasn't even reached our v0.1 goals yet, but a good chunk of important functionality is working.
fwiw, many PLs find themselves needing to have C FFI if they want to support MacOS. It's not just a convenience thing.
But couldn’t one argue that’s true of most languages, they promise incremental progress toward rewriting your behemoth into miniature monoliths? I think the only one where they clearly drew the line at being able to pull in headers is .Net. You just can’t do it. Others like Golang or rust, you can point to the C headers and bam…
Honestly, while I find the syntax terse, I welcome more low level languages able to push performance.
These are strong points and I think the methodology behind Carbon is the correct one. The elephant in the room is that once Google decide to drop Carbon my existing code base will be dependant on a dead technology and then I am screwed.
I find it hard to trust Google to maintain any software nor to write software that is maintainable by a community. They write software for themselves and themselves alone.
Then wait for Google to adopt it at large?
If it (purportedly?) exists so that Google can move multi-million line code bases from C++ to something better bit-by-bit, because it's otherwise infeasible to do so, why would Google drop it after they have ported the first million?
You can simply wait to see if Chrome adopts it.
For me Go is a success story.
I'd say Dart/Flutter is as well
I don’t think this is the only reason.
You could do this with Nim, Nim 2’s ARC model is compatible with c++’s RAII. Nim supports moves, destructors, copies, etc. see https://nim-lang.org/docs/destructors.html
You can import C++ classes, member functions, free functions, etc. easily with importcpp
importcpp for the code you are incrementally porting over. You could write a libclang script to do this for you. Exportcpp for what you any code that have been ported but have dependencies in C++ land.
My best guess is they want C++ compatibility and a new language due to preferences, more control over the compiler, etc. which are all valid reasons
> I think this page describes "what" but not "why" of Carbon.
Maybe the page was updated recently, but there is a "why" link near the top:
https://docs.carbon-lang.dev/#why-build-carbon
What I would like to see is more documentation on the "why not" that summarizes why other languages and proposals are not sufficient. For example, Safe C++ proposal[1] appears to satisfy all requirements, but I can't find any reference to it.
[1] https://safecpp.org/draft.html
The reason the Safe C++ proposal wasn't mentioned is that it came years later. =] I'll see if it makes sense for us to update that section a bit, this probably isn't the only thing that we should refresh a bit to reflect the last few years of developments.
FWIW, the biggest challenge with Safe C++ is that WG21 rejected[1] that direction. And it was developed without building a governance model or way to evolve outside of WG21, and so doesn't seem to have a credible path forward.
[1]: FWIW, some members of WG21 don't agree with this characterizationp, but both the author's impression and the practical effect was to reject the direction.
To your footnote, this has been a constant refrain from WG21. One of the biggest achievements from yourself and many others was getting WG21 to explicitly reject P2137 the "Goals and priorities" paper rather than dithering and refusing to commit as happened for "Safe C++" and for the ABI paper.
I believe that getting WG21 to actually say "No" was very useful to have non-technical leadership people understand that C++ can't be the solution they need.
Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation? Circle, as far as I know, is closed-source.
> Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation?
Technically speaking the clauses on either side of the "or" aren't mutually exclusive. You can have a "full, correct, fully compliant, reference implementation" that is also a closed-source implementation!
Well, unless the implication that Circle isn't "full, correct, [and] fully compliant", in which case I feel I should ask "with respect to what?" and "why do you need those requirements?"
But Safe C++ and Circle are different languages, right? And Circle is not the same as the Safe C++ proposal that was submitted, right? There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere. I cannot find any occurrences of "reference implementation" in the Safe C++ draft.
> But Safe C++ and Circle are different languages, right?
Eh, bit of a mixed bag, I think, depending on the context in which the words are used. "Circle" can refer to the compiler/toolchain or the set of C++ extensions the compiler implements, whereas Safe C++ is either the proposal or the extensions the proposal describe. As a result, you can say that you can compile Safe C++ using Circle, and you can also describe Safe C++ as a subset of the Circle extensions. I wouldn't exactly describe the lines as well-defined, for what it's worth.
> There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere.
They're sort of documented indirectly, as far as I can tell. Compare the features in the Safe C++ proposal and the features described in the Circle readme [0]. That'll get you an approximation at least, albeit somewhat shaded by the old docs (understandable given the one-man show).
> I cannot find any occurrences of "reference implementation" in the Safe C++ draft.
The exact words "reference implementation" may not show up, but I think this bit qualifies (emphasis added):
> Everything in this proposal took about 18 months to design and implement in Circle.
[0]: https://github.com/seanbaxter/circle/blob/master/new-circle/...
If they're the same language, then I think it's a fair objection that it's closed-source, as some people might find using a closed-source compiler to be unsuitable as a replacement for the existing open source C++ ones. If it's not the same language, then it's not clear that Safe C++ actually exists today, so it also seems fair that people might be interested in alternatives that they expect might be available sooner.
I don't think the objection in the first sentence makes sense because I don't think replacing the existing C++ compilers was ever in the cards. If anything, the fact that the Safe C++ proposal has a section titled "Implementation Guidance" seems to point to precisely the opposite - that the intent was for existing C++ compilers to be updated to add the new features, not that Circle was to replace them.
I'm not sure about the second sentence either? Circle (supposedly?) implements everything in the Safe C++ proposal, so in that respect Safe C++ exists. Alternatively, you can say Safe C++ doesn't exist because major compilers don't implement it, but that's kind of the point of the Safe C++ proposal (and many (most?) other C++ language proposals, for that matter) - it's describing new features that don't currently exist but might be worth adding to the standard.
> people might be interested in alternatives that they expect might be available sooner.
This is also a bit funny because this was one of the more contentious points of debate in the Safe C++ vs. profiles discussion, and the impression I got is that between the two Safe C++ was generally considered to be closer to "might be available sooner" than profiles.
It sounds like the difference of opinion here is around how soon we expect that the major compilers will actually implement the safe features. I tend not to be optimistic that these sorts of changes will be available anytime soon, and I think it would be fair to consider alternatives at this point, but that's obviously a judgment call and not everyone will agree on that.
As far as Safe C++ vs. profiles specifically, I don't think the conversation really ever got to the point of serious discussions of how soon the features could be implemented. My understanding is that there were bigger hangups about what direction to go in the first place as well as what "profiles" even meant.
> and I think it would be fair to consider alternatives at this point
I would assume those who could consider alternatives already have, and that those (still) interested in safe(r) C++ do so because the alternatives are insufficient for one reason or another.
Most languages including C and C++, had leading closed source implementations, that is why being standardised by ISO mattered.
But standardization also matters for avoiding vendor lock-in, right?
Like, Python and Javascript both have many "implementations", and those are some of the most popular languages. Python does not have an ISO specification. But Javascript does have an Ecma standard, ECMAScript.
Rust is getting another implementation in the form of gccrs. And there is work on a specification for Rust https://rustfoundation.org/media/ferrous-systems-donates-fer... . Arguably not a standard, but still helpful.
> Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally.
_Incrementally_: a C++ project can be incrementally made more sane also using constructs to avoid and constructs to use once the problem domain is confined. In my past, I had successfully implemented this quest for 3 different fairly large C++ projects. This is not a strong selling point for carbon.
Assuming the right culture, which unfortunately many C++ shops lack, that is why we have things like Orthodox C++ and similar movements.
i always emphasize to new programmers to learn any language and practice it with respect and discipline. All languages have dark corners, the human who can reason which constructs are appropriate.
Once you've done this work though, what stops the codebase from slowly drifting back into the less sane realm it previously resided in? It seems pretty reasonable to be concerned that a company that produced a messy codebase once is capable of making it messy again, and given that turnover is inevitable in the long term (which is the timeframe that seems relevant given that long-term compatibility in C++ codebases is kind of the whole reason this discussion is happening), it doesn't seem like relying on an individual to enforce the rules is super viable. The obvious way to enforce this sort of thing is through tooling, and there's no tool more powerful than literally making it impossible to express the undesirable code in the language itself in the first place.
You're right that incrementally rewriting isn't much of an advantage over C++ itself, but I think you're missing the point that the emphasis on "incremental" is to highlight the advantage in rewriting C++ code in Carbon over alternatives that don't provide as much compatibility (with Rust being somewhat notorious for being suggested by outside parties as a target for rewriting in whenever discussions about C++ codebases happen). The argument for Carbon over C++ isn't specifically that it can be rewritten incrementally, but that it's just a better language, which has benefits _after_ the rewrite. To be clear, I'm sure that someone could come up with reasonable objections to that claim as well, but I think it's distinct from the part you're objecting to, and it's worth treating as a separate concern.
> That's what makes Carbon different from any other language: D, Zig, Nim, Rust etc.
I know you can compile C++ files to object files, pass them to the D compiler, and have them call eachothers' functions. I've never tried it though.
--------
g++ -c foo.cpp
dmd bar.d foo.o -L-lstdc++
--------
https://dlang.org/spec/cpp_interface.html
It's a great feature, and D has a bunch of support for this kind of thing.
But D and C++ have just enough differences to make extern(C++) not be automatic. It can take some pretty arcane metaprogramming to get things to work, and some things are impossible.
It's also worth pointing out that D isn't trying to be fully compatible with C++.
A similar example is Facebook/Meta inventing Hack to progressively replacing the old PHP code.
Although it was a journey, starting with HipHop and other tools before arriving there.
Zig is designed to interoperate like this with C, and Kotlin with Java.
...and Swift w/ Obj-C
Swift can also 2-way operate with C++. Its coverage of the C++ language is incomplete but I suspect it might outpace Carbon.
I really struggle to imagine an organisation that shepherds a large and venerable C++ codebase migrating over to Swift.
For all of C++'s faults, it is an extremely stable and vendor-independent language. The kind of organisation that's running on some C++ monolith from 1995 is not going to voluntarily let Apple become a massive business risk in return for marginally nicer DX.
(Yes, Swift is OSS now, but Apple pays the bills and sets the direction, and no one is seriously going to maintain a fork.)
I saw organizations in the past do that with Java and .NET, moving away from C++.
It is perfectly feasable for companies that are full commited into Apple ecosystem.
Maybe not, but an Objective-C++ codebase might be a good candidate.
Do you have projects with huge code bases of Obj-C++ in mind?
I guess, some Mac apps? In that case I think most platform independent "guts" would be in C or C++, and the Obj-C++ part is tied to the frameworks, so the devs would have to rewrite it anyway.
Facebook iOS
I think Apple is largely doing this for themselves.
I need to learn more about that. I know that the Ladybird folks want to use it inside their C++ project.
The real "why" is because, unlike other languages, Google can't strong-arm or bribe C++'s ISO committee into doing its bidding, and that has caused problems for Google in the past. Carbon is a language born out of a corporate hissy fit.
Depends on how much people one sends to WG21 voting sessions, some folks at Reddit would assert contracts only got into C++26, thanks to Bloomberg votes.
In which way is C++ an "objectively pretty bad language"?
I have done C++ for a living and it is not the easiest but there is tooling and warnings as errors that catch a lot of the errors before even you make a mistake.
It is true that packaging is more challenging but it is also true that it is very configurable ro squeeze performance as much as possible (which is on of C++'s niches). And by squeezing I mean beyond setting a release build. You could for example decide to go with LTO + PGO + remove position independent code and do static linking for all dependencies, for example.
You can do virtually anything that no other language can do and whwn you need it, believe me it is useful.
But you can still code every day code wirh your lambdas, ranges, smart pointers and virtual interfaces.
I understand C++ has some baggage but is is very far from being an "objectively bad language" in ly opinion. More so if you take into account its performance and library availability, which is second to none for almost any task, except maybe for the typical enterprise-like Java app or web stuff, byt niw C++26 will include reflection and annotations, so this could be a game changer.
Explicitly and between the lines, Carruth and Google have made it clear that the “bad” part of C++ from their perspective is the standards committee.
In particular, the committee’s unwillingness to make ABI-breaking changes to the language, or more abstractly, to consider the needs of organizations with huge active code bases at least as seriously as those with huge legacy code bases.
I understand but there are trade-offs there.
Maybe a hybrid approach should be done byt breaking ABI in a so Core-supported language can cascade into so many places.
People say that Rust is great bc of that but that is just a trade-off and anyway there are olenty of dependencies like Boost, Abseil or others that can play that role anyways
That seems like a really neat idea.
One other use case I could think of is gaming, where there is an incredible amount of load-bearing C++ code that's never realistically going to be rewritten, and strict memory safety is not necessarily a sine qua non in the way it is in other fields.
Depends on the kind of game, and lack of security is how piracy thrives.
Yeah, perhaps the GitHub README [1] had been better ... but it seemed like the most "official" page.
[1] https://github.com/carbon-language/carbon-lang/?tab=readme-o...
> 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.
One good aspect about C++ is its backwards compatibility or stability. Also a drawback, but companies not having to spend huge amounts of time, expertise and money rewriting their whole codebases all the time is something they appreciate.
Rust is often somewhat stable, but not always.
https://internals.rust-lang.org/t/type-inference-breakage-in...
https://github.com/rust-lang/rust/issues/127343
300 comments on Github.
https://github.com/NixOS/nixpkgs/pull/332176
Rust has editions, but it's a feature that it will probably take years to really be able to evaluate.
What kind of compatibility story will Carbon have? What features does it have to support compatibility?
> Rust is often somewhat stable, but not always.
> https://internals.rust-lang.org/t/type-inference-breakage-in...
> https://github.com/rust-lang/rust/issues/127343
> 300 comments on Github.
> https://github.com/NixOS/nixpkgs/pull/332176
Might worth noting that this change technically doesn't violate Rust's stability guarantees since type inference changes and/or adding new impls are exempt. Of course, that doesn't really help with the question of whether this change should have been made in the given timeframe (as opposed to the socket struct change IIRC?), but that ship has long sailed.
I wonder if the guarantees could be amended, considering the reactions from the Rust community.
They could be amended, but I suspect they will not be. There's a reason those exemptions were added in the first place, and the impression I get is that the 1.80 issues were more of a social problem that doesn't significantly change the reasons the exemptions were added in the first place.
In addition, as I mentioned I don't think this is the first time Rust has had to navigate this kind of wide-ranging technically-allowed-but-still-breaking change. The Rust devs first created a PR to change its internal representation for IP addresses in November 2020 [0], but multiple major libraries (including mio, which tokio depends on) incorrectly assumed that the representation for Rust's IP address type was the same as libc's representation and basically type punned between the two, so the change would result in UB. The Rust devs could have pushed out the change anyways, as the change didn't violate the backwards compatibility guarantee due to just being an internal implementation detail change, but the PR didn't actually land until July 2022 [1] because the Rust devs wanted to give the ecosystem time to migrate.
More discussion at [2].
[0]: https://github.com/rust-lang/rust/pull/78802
[1]: https://github.com/rust-lang/rust/pull/78802#event-709670882...
[2]: https://old.reddit.com/r/rust/comments/wcw93o/a_major_refact...
Yes, this was a social issue more than a technical one.
At the same time, I was affected by this breakage, and it took me all of ten minutes to fix. So I both understand the outrage, and agree with it in general, but also, it was a tad overblown, I think.
Should they have done a slower rollout, like the IpAddr change? Probably. Is it the end of the world that they made a mistake? Nah. But if it happens more often, that's cause for concern.
I can write C++98 or C++11 code that will fail in a C++23 compiler, because C++ also isn't 100% backwards compatible.
But the changes required are generally significantly smaller and less frequent, right?
If the build breaks when changing the value of -std= (or equivalent), it hardly matters how big it is.
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.
> 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.
FWIW, we're working hard whenever looking at an aspect of the language to look at other languages beyond C++ and learn any and everything we can from them. Lots of our design proposals cite Swift, Rust, Go, TypeScript, Python, Kotlin, C#, Java, and even Scala.
Make sure you're checking out Hylo. I'm not sure that its ideas are right for Carbon, but if you're looking for a credible alternative to Rust's take on safety, I think it's one of the better ones.
We've been watching closely since before the name change. =D Had lots of conversations with several of the folks involved.
Chandler I would love to be involved in Carbon development to shape its development to be usable at my company or alternatively to use it in my own projects. What is the best way to stay involved in Carbon development? Just the discord?
In increasing order of volume of material:
- Our newsletter / announcements via GitHub Discussions[1] email[2] or RSS[3]
- The "Last Week in Carbon" posts via GitHub[4] or RSS[5]
- The Discord server: https://discord.gg/ZjVdShJDAs
[1]: https://github.com/carbon-language/carbon-lang/discussions/c...
[2]: https://groups.google.com/a/carbon-lang.dev/g/announce
[3]: https://github.com/carbon-language/carbon-lang/discussions/c...
[4]: https://github.com/carbon-language/carbon-lang/discussions/c...
[5]: https://github.com/carbon-language/carbon-lang/discussions/c...
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.
> 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.
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.
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.
C++ 26 doesn't have the technology, but it wouldn't matter anyway because what's crucial about Rust isn't the technology it's the culture.
If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does.
Beyond that though, the profiles idea is dead in the water because it doesn't deliver composition. Rust's safety composes. Jim's safe Activity crate, Sarah's safe Animals crate and Dave's safe Networking crate compose to let me work with a safe IPv6-capable juggling donkey even though Jim, Sarah and Save have never met and had no idea I would try that.
A hypothetical C++ 29 type safe Activity module, combined with a thread safe Animals module, and a resource leak safe Networking module doesn't even get you something that will definitely work, let alone deliver any particular safety.
> If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does.
But Rust allows pattern matching on floats.
https://play.rust-lang.org/?version=stable&mode=debug&editio...
Rust Zulip is C++ WG21 confirmed?
I'm sure you think this was somehow succinctly making your point, but I can't see any connection at all, so if you did have an actual point you're going to need to explain it.
Float matching in Rust is not supported due to correctness concerns, but due to historical accidents and backwards compatibility.
https://github.com/rust-lang/rust/issues/41620#issuecomment-...
https://github.com/rust-lang/rust/pull/84045#issuecomment-82...
OK? I don't see how that's connected? It's not controversial that f32 and f64 are partially ordered, the problem in C++ is that the difference between "Partially Ordered" and "Totally Ordered" is semantic not syntactic in their language and all semantic mistakes are just IFNDR so it's a footgun.
Yeah, that sums it all quite nicely, see contracts proposal as a good example of that.
[dead]
I'd say the C++ community is torn.
Some part of it want C++ to be Rust, with a focus on compile-time safety. Others take "C++" literally as "C with extra stuff" and value performance over safety.
Companies like Google are likely to be in the former camp, as for what they are doing, security is critical. Unsurprisingly, Carbon is a Google project.
Video game companies on the other hand are likely to be in the latter camp. Most of the times, security is not as critical, especially for offline games, and memory corruption usually don't go further than a game crash. Tight memory management however is critical, and it often involves raw pointers and custom allocation schemes.
I blame the "we won't recompile anything ever" stance from the financial organisations for the breakdown. It means C++ cannot fix mistakes, even when they harm performance, under the general name of "abi stability".
Thus there is an opening for a faster language. And still for a safer one. And for an easier one to use. So all C++ has going for it is inertia. It's moribund unless the committee reconsider their stance on intentionally losing the performance competition.
Will Carbon improve the ABI situation? Will Carbon be easier to interface with from other languages?
A major role that C plays today is being the common protocol all languages speak[0]. C++ can't fill this role, and neither can Rust.
There is a huge opportunity for some language to become the next common protocol, the common ABI, that all languages share in common.
(Maybe Rust could do this, but they haven't stabilized their ABI yet, and I don't the details.)
[0]: https://faultlore.com/blah/c-isnt-a-language/
I remember reading that google tried to impress on WG21 and 14 the need to update the ABI and they were utterly opposed. The result is google is no longer interested in C++. Apple I think is also no longer interested in C++. I think also Swift now has a stable ABI.
A good write up of that is at https://cor3ntin.github.io/posts/abi/
It's implied if you know, but Corentin's post doesn't actually link Titus's C++ proposal P1863 "ABI: Now or Never" which is what we're most concretely talking about here.
Titus correctly predicts the committee's actual response and highlights its danger, summarised in the title. You can pick now, as Corentin desires. You can pick never, which Corentin despairs at - not unreasonably because it means you're giving up performance. But Titus highlights the third option, the committee can instead dither forever never having the courage to announce an ABI break but also lacking courage to declare absolute stability with the encouragement that brings for legacy systems.
ABI Now is - at least in performance - competing with Rust. An ABI swap can make some C++ have the same performance as the analogous Rust which wasn't possible with the old ABI and that matters for outfits like Google.
ABI Never is a different niche. Guaranteed ABI stability gives C++ certainty. It makes C++ a stronger contender for some applications where today it can't go and nor can Rust because people don't think "Just recompile" is a reasonable choice, whether they are correct or not.
ABI Dither is neither of these things. There is no certainty, just because the committee is dithering today doesn't mean they won't make a decision tomorrow, or next year. But meanwhile you're not competitive with the best in class alternatives
Well it's not really C that fills that role it's the C ABI which any language can use without an ounce of C. Rust can use the C ABI.
It would be nice if there was a somewhat higher level ABI that languages could use though. The C ABI is very low level and tedious.
Carbon is performance-first, so ABI instability is the default. We plan to have opt-in ABI stability, but that story is not well developed yet. Replacing C as the lingua franca is not a goal, at least not yet.
Carbon is just trying to bring a rust-like edition to cpp, there's no reason for non cpp users to Carbon.
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.
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.
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
no need for memory safety to be in the language. It can still be checked at compile-time:
https://www.youtube.com/watch?v=ZY_Z-aGbYm8
This is a cool project, but it doesn’t address my original issue with Zig, which is that the language’s semantics is not even specified. That is, we cannot define what a “memory safe Zig program is” as we cannot even define what a Zig program is! (Unless you define the semantics of a Zig program in terms of the implementation/translation to IR, which is fragile / bad.)
Second, I would be surprised if the static analyses in the tool are precise enough for real-world Zig programs. For example, it is undecidable to determine whether a function “takes ownership” of an argument pointer. In particular, if you want to avoid false negatives, the “free after transfer” case needs to be conservative, but then you almost certainly will flag false positives.
of course. There will absolutely need to be a way to specify intent in certain cases or override the judgement of the checker. That may come in the form of external annotation, or possibly internal annotation, which in principle is achievable using the same technique as you see in the "unitful" demo, though that's not ideal.
as for zig being specified, well, it's pre 1.0, and the authors have I believe, specifically called out specification as being "the first priority after 1.0".
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
> 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.
It means eliminating undefined behavior, and unplanned interaction between distant parts of the program.
Eliminating undefined behaviour is a means to an end (reduces problematic bugs, but not all undefined behaviour is equally responsible to such bugs), and it's not a binary thing (virtually all programs need to interact with software written in languages that don't eliminate undefined behaviour, so clearly there's tolerance to the possibility of undefined behaviour).
Don't get me wrong - less undefined behaviour is better, but drawing a binary line between some and none makes for a convenient talking point, but isn't necessarily the sweet spot for the complicated and context-dependent series of tradeoffs that is software correctness.
By definition all the C++ Undefined Behaviour is unbounded. You may believe, and even you may have practical evidence for the compilers which happen to exist today, that in some cases the behaviour in fact bounded, but that's not what the language definition says and optimisers have a funny way of making fools of people who mistake Undefined for "Eh, it'll probably do what I meant".
It might seem as though incrementing a signed integer past its maximum can't be as problematic as a use after free even though both are Undefined Behaviour, but nah, in practice in real C++ compilers today they can both result in remote code execution.
There is a place for Unspecified results, for example having it be unspecified whether a particular arithmetic operation rounds up or down may loosen things up enough that much faster machine code is generated and well, the numbers are broadly correct still. But that's not what Undefined behaviour does.
Yes, that's what UB means - the program loses all meaning and any effect is possible - but the importance of a bug is much more than just its blast radius. We ultimately care not about the language semantics of a bug but its expected loss of value. This is also dependent on how frequently the bug appears and how easy it is to prevent or find and fix. Not all UBs are equal on that front.
Furthermore, an unbounded blast radius isn't itself the direct problem. A bug that with some probability casues your program to crash and your disk to be deleted is far less dangerous than a bug that allows a remote attacker to relatively easily steal all your secrets. UBs also differ on that front.
And again, virtually all programs are not provably without UB. For example, a Java program still interacts with an OS or with some native library that might suffer from a UB. So clearly we do tolerate some probability of UB, and we clearly do not think that eliminating any possibility of UB is worth any price.
When a program is just code on the screen, it's just a mathematical object, and then it's easy to describe a UB - the loss of all program meaning - as the most catastrophic outcome. But software correctness goes beyond the relatively simple world of programming language semantics, and has to consider what happens when a program is running, at which point it is no longer a mathematical object but a physical one. If a remote attacker steals all our secrets, we don't care if it's a result of some bug in the program itself (due to UB or otherwise), in other software the program interacts with, some fault or weakness in the hardware, or human operator error. The probability of any of these things is never zero, and we have to balance the cost of addressing each of these possibilities.
To give an example in the context of Carbon, we know that old code tends to suffer from fewer severe bugs than new code. So, if we want to reduce the probability of bugs, it is possible that it may be more worthwhile to invest - say, in terms of language complexity budget - in interop with C++ code than in eliminating every possible kind of UB, including those that are less likely to appear, sneak past testing, and cause an easily exploitable vulnerability.
> the most catastrophic outcome
Nah, this is in the context of C++ so UB isn't the most catastrophic situation. Undefined Behaviour is a behaviour, which means we might well be able to avoid invoking the behaviour and then it's fine. For example if your C++ program has a use-after-free in the code invoked only by the "Add file" feature but otherwise works fine, we can just ensure operators never use "Add file" and the UB, no matter what it might be, won't happen.
C++ has IFNDR, clauses which say this is "Ill-Formed, No Diagnostic Required". The program itself wasn't actually a valid C++ program, it has absolutely no defined meaning, there may be no indication of a problem from your compiler but alas it's entirely meaningless. This isn't behavioural, it's an invisible status of the entire program.
As I said, UB means that a program has no meaning in the source language. That doesn't change anything I wrote above about the impact of UB. A hardware fault may also make a program meaningless, BTW, yet we all accept that every program written in any language is currently susceptible to UB or to a hardware fault.
If you want, you can think of UB like a mathematical singularity in some physical theory. The theory of the language has nothing to say about what happens in such a program. But that doesn't mean that we can't reasonably talk about what happens not using that theory [1]. Indeed, one of the reasons that UB are of concern is that some of them are frequent causes of security exploits - and that's the thing we ultimately care about, not that the program loses its semantics. But again, not all of them are equally common causes of such outcomes, and not all of them are equally hard to avoid in the first place.
[1]: In fact, this is easy to explain in software: the programming language can say nothing about the meaning of a program with UB - indeed, it has no meaning in that language - but because we do have an executable, the program still has a well-defined meaning in the machine language it compiled to (machine language has no UB, or, even if some machine architecture does declare that some instruction stream is UB, most programs with UB in some programming language still do not compile to a program with UB in machine code). So the program that has no meaning in C++ still has meaning in machine code, and as that is the program we ultimately run and care about, we can talk about which UBs are more or less likely to result in which machine code behaviour.
This seems like it missed the point entirely?
UB is a behaviour, it's unbounded, so it's an immediate disaster, and "time travel" UB can make this harder to reason about, because the as-if rule can mean that although it didn't in some sense "happen" yet the behaviour has consequences earlier. But if we avert the behaviour it won't happen. It is not correct to say that UB means the entire program had no meaning.
You give the "mathematical singularity" analogy, consider division. We doubtless agree than 6 divided by 3 is 2. And 6 divided by 2 is 3. But how about 6 divided by 0? This is not defined, we cannot perform such an operation. But division is not as a result somehow entirely without meaning, it just has this well understood limitation. Likewise for software with UB that we can avert.
IFNDR is a catastrophe because it truly does render the entire software without meaning.
> IFNDR is a catastrophe because it truly does render the entire software without meaning.
In the language. I.e. the language assigns no meaning to source the program, which is, indeed, the "catastrophic" impact of UB (or IFNDR) within the theory of the language. But since a running program takes the form of an executable, and the executable always has a defined meaning in another language (machine code), while C++ has nothing to say about what such programs do (i.e. that's the end of the helpfulness of that theory) that doesn't mean we can't talk about or care about the meaning of the executable.
An executable that crashes and an executable that leaks all your secrets have very different consequences, and while the C++ spec says absolutely nothing about the relationship between different UBs and these behaviours, that doesn't mean that these relationships don't exist.
A mathematical singularity in a physical theory means that that particular theory has nothing to say about the physics of that situation, not that there's no actual physics going on, and the physics that is actually going on could be more or less "catastrophic" depending on what we mean by that.
To be more concrete, event though two programs can both be meaningless in C++, i.e. C++ says nothing about what they actually do once compiled and run, we can sometimes say that one of them is much more likely to lead to a security exploit than the other. This is even used in practice in techniques such as this one: https://www.cl.cam.ac.uk/~tmj32/papers/docs/ainsworth20-sp.p...
Splendid reply! I'm a big fan of Carbon and so I really appreciate when people make solid arguments for its tradeoff space.
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.
Swift seems to be doing a decent job of this (and C++ interop for that matter)
> Swift seems to be doing a decent job of this
It keeps adding keywords and it has become way harder to keep it in your head. It’s over 220 at this point. Don’t take my word for it, Swift creator doesn’t agree with its current direction either.
I'm not sure why I should take the word of the guy who added a bunch of these keywords so he could use Swift for AI
Curious, what keywords were those? I think Chris Lattner was not involved with Swift after version 3
https://github.com/swiftlang/swift/blob/main/docs/Differenti...
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
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.
Stockholm syndrome, after learning C++ syntax, surely it wasn't all for nothing, I can't accept that.
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.
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.
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.
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.
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.
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++.
This was essentially how DMD (the reference D compiler) was translated to D. However this was mostly a restricted subset of C++ common to both of them, e.g. no diamond inheritance, no operator overloading whackiness.
Nim would be the best choice for this at the moment, imho
importcpp what you need. exportcpp for the other way around
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.
[] 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.
`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.
How is it inconsistent? The square brackets always mean "this was deduced" and the parens always indicate "this was passed in explicitly"
Square brackets do not indicate "this is a type". Instead they indicate "these things were deduced from their context"
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.
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.)
The joke is that no* c++ dev actually likes the bracket syntax for templates.
* I might be slightly exaggerating.
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.
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?
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.
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?
I think they had another such effort for a while here: https://github.com/google/crubit
Are all major programming languages going to come from corporations in web 2.0?
Where do you think even C and C++ came from?
Web 2.0?
Probably referring to "large tech companies that grew in the Web 2.0".
Yeah, agree that it sounds slightly off initially.
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?
What's the pro of not having a stable ABI?
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/
> 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.
[2022]
It's an ongoing project, specifying a date here wouldn't make much sense.
is there any news? the website has no information and doesn't really highlight anything other than their launch at a conference in 2022.
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
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].
[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.
What's wrong with fn? It's perfectly understandable. I don't understand what the bikeshedding about keywords like this is about.
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.
fun is the best, as it makes the function name align with the code block indented 4 characters :D
0 vs 1 indexing has an actual semantic difference that you have to keep in your head at ~all times, but could have a text editor plugin that rewrites func<->fn since it's purely syntactical.
What is inconvenient about it?
Keywords usually are quite pronounceable, and some of them are even proper words. How do you read fn?
Usually as "function"
fun
fn
I kind of appreciate fn, personally. It's nice having function declaration lines with two less unnecessary characters in their length.
I use emacs' prettify-symbol mode to turn every language's function keyword into ʩ. Don't think I incurred in God's wrath just yet.
Why not just write it as fun, that way you are having fun while writing a function just as (God intended,[pun intended]) :P
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.
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.
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.
It is kind of ironic how people still get stuck discussing syntax to save keystrokes and then write a whole book on the AI chat window.
Probs too archaic?
"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?
C++ does not have a function keyword at all, I wonder why did they add it in the first place.
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.
A compatibility required by C.
To avoid any possibility of reintroducing the Most Vexing Parse?
https://en.wikipedia.org/wiki/Most_vexing_parse
It doesn't, but you can pretend it does:
They probably want to use the same arrow signature and need something in place of auto as omitting it completely would complicate parsing.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 “\”.
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).
I like it the most when there's no keyword. Just name() and return type.
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.
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.
Anyone using a proper IDE instead of notepad like editor.
I have that and still prefer class, easier to type(not just shorter, but easier keys) and less to read. Only use typename in the rare case where it is required
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.
Tbh, I wonder why modern languages still have a function keyword at all, e.g.:
...or any variation of the arrow-function idea...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.
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.
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.
IMO it is far easier to read this:
Than the example you provided and it is approximately the same length. I used to arrow functions everywhere in TS/JS and it made it difficult to read IME, and there was zero benefit. They are find for things like event handlers, promises chains etc. But I'd rather just use function when I don't have to worry about the value of this.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?
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.