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.

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

> 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

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

Zig is designed to interoperate like this with C, and Kotlin with Java.

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.

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

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

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

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

Stockholm syndrome, after learning C++ syntax, surely it wasn't all for nothing, I can't accept that.

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.

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.

Web 2.0?

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

Square brackets do not indicate "this is a type". Instead they indicate "these things were deduced from their context"

It's an ongoing project, specifying a date here wouldn't make much sense.

What's wrong with fn? It's perfectly understandable. I don't understand what the bikeshedding about keywords like this is about.

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.

I kind of appreciate fn, personally. It's nice having function declaration lines with two less unnecessary characters in their length.

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.

C++ does not have a function keyword at all, I wonder why did they add it in the first place.

  auto my_function(int, double) -> int;

"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?

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.

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 “\”.

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.

Tbh, I wonder why modern languages still have a function keyword at all, e.g.:

    const add = (a: i32, b: i32): i32 => a + b;

...or any variation of the arrow-function idea...

    function add(a: i32, b: i32): i32 {
        return a + b;
    }

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.