Carbon Language: An experimental successor to C++

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.

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

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.

> 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

A similar example is Facebook/Meta inventing Hack to progressively replacing the old PHP code.

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.

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...

> 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.

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.

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.

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

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

Swift seems to be doing a decent job of this (and C++ interop for that matter)

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.

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.

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

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.

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

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/

Where do you think even C and C++ came from?

Web 2.0?