Carbon instead of Rust? Which is the true successor of C++
By Tomasz Kuczma
Carbon, a new programming language by Google that was announced at CppNorth 2022 conference as part of the presentation “Carbon Language: An experimental successor to C++” by Chandler Carruth on July 22nd 2022 (link ). The news spread quickly over the Internet and a few friends reach out to me to ask about my opinion about it and if Rust is going to die because of the appearance of a new baby of a big player in this industry. Well, Rust is doing fine and I will summarize my thoughts about Rust, Carbon, and modern C++ (C++20 standard as of today).
Why did Google decide to invest in Carbon?
Designing and maintaining a new language is a huge cost so why did Google decide to do so? In the first place, it is worth noticing that C++ is a good language to write high-performance code. Over time, a set of useful tools were developed around it. It’s a popular, well-known, and very stable language that maintains backward compatibility. Backward compatibility is a huge feature but comes at a great cost. Sometimes this cost is an impossibility to fix “mistakes” in the design which cause a significant cost to work around it while developing new language features and coding in that language. The big burden of C++ is its compatibility with plain C language (e.g. preprocessor, memory management to name a few) which was probably a giant enabler to adopt this language back in the late 1980s but nowadays makes it super error-prone and hard to add new features. This cost is basically main reason for a new language. More of that you can read in the official Carbon doc: difficulties improving cpp .
Carbon goals and Hello world!
Carbon design tenets are:
- provide two-way interoperability between C++ and Carbon without an overhead to allow smooth migration
- improve the syntax of C++ and development experience (add simplification, and briefness) by breaking backward compatibility of the syntax level to improve development experience
- improve memory safety as much as possible
From the documentation , I got an impression that this is the order of precedence e.g. memory safety is less important than two-way interoperability which I will comment on later on.
There are two examples available right now (source ):
// C++ code used in both Carbon and C++:
struct Circle {
float r;
};
// Carbon exposing a function for C++:
package Geometry api;
import Cpp library "circle.h";
import Math;
fn PrintTotalArea(circles: Slice(Cpp.Circle)) {
var area: f32 = 0;
for (c: Cpp.Circle in circles) {
area += Math.Pi * c.r * c.r;
}
Print("Total area: {0}", area);
}
// C++ calling Carbon:
#include <vector>
#include "circle.h"
#include "geometry.carbon.h"
auto main(int argc, char** argv) -> int {
std::vector<Circle> circles = {{1.0}, {2.0}};
// Carbon's `Slice` supports implicit construction from `std::vector`,
// similar to `std::span`.
Geometry::PrintTotalArea(circles);
return 0;
}
package Sorting api;
fn Partition[T:! Comparable & Movable](s: Slice(T))
-> i64 {
var i: i64 = -1;
for (e: T in s) {
if (e <= s.Last()) {
++i;
Swap(&s[i], &e);
}
}
return i;
}
fn QuickSort[T:! Comparable & Movable](s: Slice(T)) {
if (s.Size() <= 1) {
return;
}
let p: i64 = Partition(s);
QuickSort(s[:p - 1]);
QuickSort(s[p + 1:]);
}
Few things worth noticing:
- It’s super easy to call C++ code in Carbon and vice-versa.
import Cpp library "circle.h"parsescircle.hfile and produces C++ AST (abstract syntax tree) that is mapped to Carbon AST. The opposite happens if you include a Carbon module in C++ (this was mentioned in the presentation). That makes migration an easy and iterative process which is a key for adaptation. This is also an important feature that allows goals 1 and 2 to coexist. - Syntax is inspired by other modern programming languages so the learning curve shouldn’t be steep
- Templates like
[T:! Comparable & Movable]uses something similar to C++20’s “Constraints and concepts” (see more here ) which should make templates more robust than in old C++. Note that a similar mechanism is also available in Rust (traits and generic types).
Overall, I would say that Google made a pretty good improvement to modern C++20. Personally (judging from what was presented so far), I would call it more like syntax sugar for C++20 since it promises to work without overhead even for advanced C++ concepts (like advanced templates). Syntax sugar but still good improvement though.
“If you can use Rust, ignore Carbon”
Rust is a great language. And even official Carbon documentation says “If you can use Rust, ignore Carbon” - see Why not Rust? . Rust provides a way to operate with C and C++ using FFI (Foreign Function Interface) - see my previous article about Rust and Cpp interoperability but sometimes it might require more coding in some corner case e.g. to workaround some advanced C++ templates. It also gives much better memory safety than Carbon and C++ since its goal is rather safety and performance than to be that massively one-to-one interoperable with C++ (see my other article Why not modern C++ ). That is a key difference between the two.
And that’s an actual problem in Google’s scale as they seem to use C++ so massively that maintaining Rust’s FFI is hard. They required something that integrates more smoothly with C++ and that’s the reason why Google didn’t decide to simply use Rust everywhere.
They still use Rust though as much as I can tell from public sources and even provided a great autocxx library that aims to take a similar “super automated” approach for Rust FFI binding that addresses their massive C++ codebase scale.
Summary
Is Carbon going to replace C++ and Rust? C++ maybe, at least in Google codebase :) Rust? Definitely not as it gives much more significant improvement over C++ (memory safety, much simpler language and concept of OOP, safe concurrency, etc) than Carbon. Carbon looks more like syntax sugar for C++.
But maybe Carbon is some intermediate step that we need. Rust already pass through some early development phase of “changing the approach” between versions 0.2 and 0.4 (where the concept of classes was removed). So maybe at some point Carbon will become a bridge or intermediate step that allows migration from C++ to safe Rust via Carbon “semi-safe” bridge. We’ll see what the future brings.
BTW, Facebook just announced that they added Rust to their list of supported server-side languages which means that developers will receive long-term support for that. It’s officially recommended in 2/5 categories: CLI tools and performance-sensitive back-end services (details ). In my opinion, it also highlights Rust’s high position on the stage.
Software engineer with a passion. Interested in computer networks and large-scale distributed computing. He loves to optimize and simplify software on various levels of abstraction starting from memory ordering through non-blocking algorithms up to system design and end-user experience. Geek. Linux user.