←back to thread

155 points samuell | 1 comments | | HN request time: 0.648s | source
Show context
kjksf ◴[] No.44749375[source]
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.

replies(14): >>44749770 #>>44750227 #>>44750232 #>>44750657 #>>44751685 #>>44751728 #>>44752039 #>>44752523 #>>44752948 #>>44753844 #>>44754061 #>>44756351 #>>44758133 #>>44758430 #
cb321 ◴[] No.44749770[source]
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.

replies(4): >>44750077 #>>44751953 #>>44752008 #>>44753027 #
1. duped ◴[] No.44750077[source]
fwiw, many PLs find themselves needing to have C FFI if they want to support MacOS. It's not just a convenience thing.