Comment by kjksf
3 days ago
I think this page describes "what" but not "why" of Carbon.
Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally.
The most important attribute of Carbon is not the specifics of the syntax but the fact that it's designed to be used in a mixed C++ / Carbon code base and comes with tooling to convert as much of C++ as possible to Carbon.
That's what makes Carbon different from any other language: D, Zig, Nim, Rust etc.
It's not possible to port a millions line C++ code base, like Chrome, to another language so large C++ projects are stuck with objectively pretty bad language and are forced to continue to use C++ even though a better language might exist.
That's why Carbon is designed for incremental adoption in large C++ projects: you can add Carbon code to existing C++ code and incrementally port C++ over to Carbon until only Carbon code exists.
Still a very large investment but at least possible and not dissimilar to refactoring to adopt newer C++ features like e.g. replacing use of std::string with std::string_view.
That's why it's a rational project for Google. Even though it's a large investment, it might pay off if they can write new software in Carbon instead of C++ and refactor old code into Carbon.
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 }.
3 replies →
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 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.
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'.
1 reply →
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?
1 reply →
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?"
4 replies →
Most languages including C and C++, had leading closed source implementations, that is why being standardised by ISO mattered.
1 reply →
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.
> 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.
7 replies →
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
> 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 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.
2 replies →
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?
1 reply →