alt Hacker NewsI 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.
Replies
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.
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.
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.
> 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.
A similar example is Facebook/Meta inventing Hack to progressively replacing the old PHP code.
> 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++
--------
Zig is designed to interoperate like this with C, and Kotlin with Java.
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.
> 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?
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.
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...
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.