rust VS carbon-lang

RisingWave is a high-performance streaming database built in Rust. It’s PostgreSQL-compatible and lets users write sophisticated stream processing logic using standard SQL - no need to learn a new DSL or framework.

Rust development is experiencing major growth in 2025 as its developers continue to focus more on performance, memory safety, and reliability of their code. Supported by a powerful compiler, with modern tooling and an emerging ecosystem, Rust is an alternative to the majority of the limitations of legacy systems programming languages. This blog discusses the theoretical basis behind the transition to Rust-based development and the reasons why it is rapidly growing as an attractive option to software engineers and organizations.

https://www.rust-lang.org/ https://doc.rust-lang.org/cargo/ https://doc.rust-lang.org/cargo/getting-started/installation.html

I am very sorry, but you do not address that TBAA, like C has by default, generally is easier than just no aliasing, like what Rust has for mutable references. This is a major difference. C code can opt into a similar kind of aliasing, namely by using _restrict_, but that is opt-in, while it is always on for Rust.

And there is newer UB as well in Rust stdlib

https://github.com/rust-lang/rust/pull/139553

Real-world programs can be verified by formally proving properties on a small part of the code (called the kernel) in a way that transitively guarantees those for the remaining code.

For example, Rust's borrow checker guarantees* memory safety of any code written in Rust, even a 10M+ LOC project. Another example is sel4, a formally-verified micro-kernel (https://sel4.systems/About/seL4-whitepaper.pdf).

* Technically not; even if the code doesn't use `unsafe`, not only is Rust's borrow checker not formally verified, there are soundness holes (https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3A...). However, in theory it's possible to formally prove that a subset of Rust can only encode memory-safe programs, and in practice Rust's borrow checker is so effective that a 10M+ LOC project without unsafe will still probably not have memory issues.

Backend: Rust

What's weird about this?

To understand what evil_lincoln is doing, you have to understand very old Rust. Here's the commit that introduced it: https://github.com/rust-lang/rust/commit/664b0ad3fcead4fe4d2...

    fn evil_lincoln() {

Side note: There's an effort to cache proc macro invocations so that they get executed only once if the item they annotate hasn't changed: https://github.com/rust-lang/rust/pull/129102

There are multiple caveats on providing this to users (we can't assume that macro invocations are idempotent, so the new behavior would have to be opt in, and this only benefits incremental compilation), but it's in our radar.

The latest Carbon newsletter is here, from March: https://github.com/carbon-language/carbon-lang/discussions/5...

There has been talk of new language frontends for C++:

Cpp2 (Herb Sutter's brainchild): https://hsutter.github.io/cppfront/

Carbon (from Google): https://github.com/carbon-language/carbon-lang

In principle those could enable a safe subset by default, which would (except when explicitly opted-out) provide similar safety guarantees to Rust, at least at the language level. It's still up to the community to design safe APIs around those features, even if the languages exist. Rust has a massive advantage here that the community built the ecosystem with safety in mind from day 1, so it's not just the language that's safe, but the APIs of various libraries are often designed in an abuse-resistant way. C++ is too much of a zoo to ever do that in a coherent way. And even if you wanted to, the "safe" variants are still in their infancy, so the foundations aren't there yet to build upon.

I don't know what chance Cpp2 or Carbon have, but I think you need something as radical as one of these options to ever stand a chance of meaningfully making C++ safer. Whether they'll take off (and before Rust eats the world) is anyone's guess.

Kind of along these lines but for C++: https://docs.carbon-lang.dev/

2. There are certain safety problems that simply can't be solved in C++ unless you accept that ABI will be broken and the language won't be backwards compatible.

Circle (https://www.circle-lang.org/site/index.html) and Carbon (https://docs.carbon-lang.dev/) were both started to address this fundamental issue that C++ can't be fully fixed and made safe like Rust without at least some breaking changes.

This article goes into more depth: https://herecomesthemoon.net/2024/11/two-factions-of-cpp/

In the case of the Linux kernel, a lot of the newer features that C++ has delivered aren't _that_ useful for improving safety because kernel space has special requirements which means a lot of them can't be used. I think Greg is specifically alluding to the "Safety Profiles" feature that the C++ committee looks like it will be going with to address the big safety issues that C++ hasn't yet addressed - that's not going to land any time soon and still won't be as comprehensive as Rust.

People like to always talk about Carbon like that, yet the team is the first to point out anyone that can use something else, should.

Carbon is an experiment, that they aren't sure how it is going to work out in first place.

> "If you can use Rust, ignore Carbon"

https://github.com/carbon-language/carbon-lang/blob/e09bf82d...

> "We want to better understand whether we can build a language that meets our successor language criteria, and whether the resulting language can gather a critical mass of interest within the larger C++ industry and communit"

https://github.com/carbon-language/carbon-lang/blob/e09bf82d...

The Carbon Language repo on GitHub maintains an impressive deployment frequency, consistently pushing updates at a rapid pace. With an average of over 74.67 deployments per month---hitting 79 in July 2024 alone---Carbon is setting the pace for fast, efficient software delivery. But is there a price for going this fast?

I for one started working on a new project in C++ rather than Rust. I think it's unclear whether Rust is going to be the successor at this point. It's probably never going to pick up in the games industry, QT is C++ (and Rust bindings will always be second class or they could end up unmaintained), has better compile times and is said to be undisputed when it comes to high performance. Obviously the tool for the job factor is most critical.

Career wise, many people are picking up Rust and almost no one is picking up C++, while experienced C++ devs either retire or switch to a higher level language due to landscape change. I would trust supply and demand to be in favour of C++ 10 years from now.

There are also attempts to make C++ more memory safe like Carbon[1] or Circle compiler [2]. If they succeed, why would anyone want to switch to Rust? Also Rust is not ideal for security from a different perspective - I think the lack of a package manager is one C++ strongest points. After working for 9 years with npm, you really appreciate that the dependency you install is usually just a single dependency (even an option for a single header file is common), when there's a package manager, people will abuse it (like install a package with 3 dependencies of its own for something that could be 50 LOC copy-paste) and managing the security of the supply chain is nearly impossible (it will be a legal requirement soon in EU though).

Anyway, I wanted to ask. How is the contracting market looking in C++ world? I'm guessing it depends on the domain heavily? I'm mainly asking about QT and anything that would be desktop / mobile apps / systems programming except video games, but I'm curious in general.

[1] https://github.com/carbon-language/carbon-lang

[2] https://github.com/seanbaxter/circle

Thanks for clarifying that point. It's worth pointing out that the safety strategy doc[0] mentions that

>A key subset of safety categories Carbon should address are:

>[...]

>Data race safety protects against racing memory access: when a thread accesses (read or write) a memory location concurrently with a different writing thread and without synchronizing

But then later in the doc it says

>It's possible to modify the Rust model several ways in order to reduce the burden on C++ developers:

>Don't offer safety guarantees for data races, eliminating RefCell.

>[...]

>Overall, Carbon is making a compromise around safety in order to give a path for C++ to evolve. [...]

One could read this as saying that guaranteed safety against data races is not a goal. Perhaps this doc could be reworded? Maybe something like "Carbon does not see guaranteed safety against data races as strictly necessary to achieve its security goals but still we still currently aim for a model that will prevent them."

[0] https://github.com/carbon-language/carbon-lang/blob/trunk/do...