Table of Contents
Ever since Google introduced its Carbon programming language and considered it as a possible successor to C++, it caught the attention of the Rust programming language community and a debate on Google’s Carbon vs Rust language ensued. It started a conversation among worldwide developer communities that which language is going to be the true successor of C++.
In this article we will compare between Carbon vs Rust language over different parameters, talk about their differences with C++ and analyze the possibilities of them succeeding C++.
What is Rust Programming Language
Rust is a statically-typed, high-performance, multi-paradigm programming language developed at Mozilla Research in 2009. It was later released on 2015. Its primary focus is over safety, memory management, productivity, concurrency and performance. It was developed to be an easy to use, reliable and fast software.
Developers can create high performing, robust and secure applications through Rust programming language. Rust has a similar syntax to C++ and is used in cross-platform apps, backend apps, command-line tools, web assembly, etc.
In terms of Performance, Rust is not only fast but also memory-efficient. It has no garbage collector, can run on embedded devices, power performance-critical services and integrate with other languages as well.
For reliability, Rust guarantees memory and thread safety due to its rich type system, through which developers can remove bugs during compile time.
For productivity, Rust has top class documentation, user-friendly compiler, build tools, package manager, auto formatter, type inspections, etc features up its sleeve.
Rust is getting used in Dropbox, Firefox, NPM, InfluxDB, etc. It is also used to develop Operating systems like RustOS, BlogOS, Tock, Rux, etc.
What is Carbon Programming Language?
Carbon programming language is new and was publicly announced at CPP North conference on 19 July 2022. It was announced as an “experimental successor” to C++ by Chandler Carruth along with his team. Soon after the announcement, internet was flooded with the debate on carbon vs rust language and who will be the true successor to C++. Well, Carbon is still under development with no working compiler.
The primary goals of Carbon are speed, performance-critical, interoperability, easy to use code, testing and safety mechanism, modern OS platforms, and modern syntax. Since it is not in use, we cannot predict its uses yet but it is predicted to be used in development of backend systems, embedded apps, etc. One major area Carbon wants to focus on, is on developing a huge code base to store the large database of C++ codes so it will be easier for C++ successors to migrate to Carbon.
A few areas where Carbon does not wants to focus on, is on ensuring backward and forward compatibility or developing stable application Binary Interface(ABI) for the libraries and the entire language. Apart from it, Carbon has a source repository, governance model, discord and a ‘prototype’ interpreter that you can either use online or install on Linux or MacOS. It doesn’t have a compiler and a toolchain yet.
Carbon Language vs Rust Comparison
Language Interoperability ( in short interop ) is the ability of one programming language to be able to interact with a different programming language as part of the same system. So code written in one language should be compatible with code written in another language. As new languages evolve, having interoperability is a key element which can make new language adoption easy.
Comparing Carbon vs Rust interoperability with C++ :
Interoperability in Rust
Rust doesn’t have native language level support for interoperability with C++. Rust supports interop with C. However C++ interop is still not in place and an ongoing work, although it has large gap to support C++. So the common pattern is to rewrite the code in Rust instead of doing an interop with C++.
However there are external libraries like cxx and autocxx which try to solve this problem out of the box for interoperability in Rust-lang.
Interoperability in Carbon
Carbon supports bidirectional interoperability with C++. So code written in Carbon can be called in C++ using subset of library wrappers and code written in C++ can be called in Carbon easily.
This is one of the primary selling points of Carbon as they want to make migration from C++ code relatively seamless.
The C++ interoperability layer of Carbon allows a subset of C++ APIs to be accessed from Carbon code, and similarly a subset of Carbon APIs to be accessed from C++ code. This requires expressing one language as a subset of the other. Bridge code may be needed to map some APIs into the relevant subset, but the constraints on expressivity should be loose enough to keep the amount of such bridge code sustainable.
It must be straightforward for any Carbon interoperability code to be compatible with the C++ memory model. This does not mean that Carbon must exclusively use the C++ memory model, only that it must be supported.
However, the storage and representation will need to be equivalent in both languages. For example, if a C++ _int64 maps to Carbon’s int64, the memory layout of both types must be identical.
For example, a C++ class template like std::vector<T> should be usable without wrapper code or runtime overhead, and passing a Carbon type as T. The resulting type should be equally usable from either C++ or Carbon code. It should also be easy to wrap std::vector<T> with a Carbon interface for transparent use in idiomatic Carbon code.
The code uses the geometry.carbon.h library to print the area of circle.
At a very high level, garbage collection is an automatic process to clean up unused variables/references from program memory especially the heap memory. As the programs execute, variables or objects that are no longer referenced in the code accumulate space on the heap. So cleaning up these resources is important for efficient memory management. Some languages (Eg: Java, python, golang ) perform garbage collection at run time using periodic background threads to de-allocate space. Few other languages (Eg: Rust) achieve this by adding relevant cleanup code at compile time.
Garbage collection differences between Carbon and Rust are as follows:
GC in Rust
Rust is a GC free language. It manages memory cleanup using ownership mechanism. When a variable goes out of scope and is not reachable, 2 things can happen.
- Ownership of that variable can be transferred to some other variable or
- The memory associated with the out of scope variable is freed up.
All of this happens at compile time by adding relevant cleanup code. So there is no real garbage collection that happens at run time in Rust.
GC in Carbon
Carbon language does not have GC either. Just like C++, carbon provides methods to manually manage memory. In C++ we need to use new and delete to allocate and de-allocate the memory.
Similar to that Carbon language has heap.New and heap.Delete to allocate and de-allocate memory.
Although this can have some cons in terms of unwanted memory errors this is a general usage pattern for low level languages. Some of the common errors are addressed using memory safety goals of carbon.
Safety in Carbon vs Rust
Safety of a programming language involves secure mechanisms to safeguard against software bugs and security vulnerabilities. Some common safety mechanisms include Spatial Memory safety, Temporal memory safety, Type safety, Date race safety.
Safety in Rust
Safety is the first citizen in Rust. Rust supports safety at compile time. To avoid Garbage collection at runtime , Rust automatically adds relevant code based on variable scopes. This helps avoiding manual memory allocation thereby enhancing overall language safety.
Rust is memory-safe, type-safe, null-safe and thread-safe by design. If the compiler detects the code is unsafe, it throws compilation errors. Unless you specify unsafe keyword Rust doesn’t allow you to perform unsafe code.
Safety in Carbon
Carbon language has high priority to performance over Safety. It has tight goals to achieve performance similar to C++. This means some of the options like Garbage collection etc., should be manually managed (at-least initially with incremental feature addition).
Carbon main focus is the ability to perform migration from C++ with interop.
As per Carbon docs,
“The only well understood mechanism of achieving safety without giving up performance is compile-time safety. The leading example of how to achieve this is Rust.”
So as the language evolves, compile time safety similar to Rust could be an option for Carbon.
Package manager is a program / tool that can automate common development workflows like creating builds, download and install libraries or dependencies required for the codebase etc. They can interact with language specific compiler to perform builds. With package managers you can publish your own packages to a central repositories, which in-turn can be packaged into other projects easily. Some of the most frequently used package managers are maven, gradle, pip, cargo etc.
Package manager in Rust
Cargo is the package manager for Rust. Every executable program or library in Rust is called a Crate. The central repository for Rust packages is crates.io . With Cargo you can download dependencies, compile, distribute packages with Crates package registry.
Package manager in Carbon
Looking at Carbon language goals, it is projected to include package manager as part of Carbon tools and ecosystem.
“Infrastructure to enable package management and other library ecosystem support: The goal is to support what the ecosystem needs, regardless of the exact form this ends up taking.” –Source: Carbon language goals
While the exact timelines and details are not clear, keeping the current goals in mind, carbon language can include package manager as an improvement compared to C++.
Carbon vs C++
One major change Carbon developer did, was to cut out the backward compatibility feature completely. This allowed Carbon to have less technical debt than C++ as the upgrades in C++ were lengthy, manual and needed to be done after any major changes in the language. Carbon, on the other hand, offers tool-based version upgrades along with C++ migration.
Code Source- Carbon repository
The possibility of Carbon succeeding over C++ is high. With Carbon allowing bidirectional interoperability between C and C++, developers will be getting all featuers of C++ in it as well.
|Type systems||Strongly–typed; statically–typed||Strongly–typed; statically–typed|
|Expressiveness||Hardly expressive||Very expressive|
|Generics support||Templates; Similar to generics||Yes|
|Learning curve||Hard to grasp||Moderate|
Rust vs C++
Rust is often called out for being a hard to learn language, but it is not as hard as C++. Any developer who is well versed in C++ can easily pick up Rust within two weeks. A big difference between Rust vs C++ is that Rust is safe. No worries for safety regarding type and memory. It also has an unsafe attribute where you can unlock the unsafe coding. There are a few things which are marked unsafe such as calling C functions, accessing fields of a union, dereference raw pointers, etc and to use them, you have to enable the unsafe mode in Rust.
Being older, C++ has a huge community support. It also has a powerful library which is perhaps the best choice for game development. On the other hand, Rust’s positives lies in its memory safety and a slightly better learning curve than C++.
Rust has built-in features for memory safety and management which C++ doesn’t. In order to be fast, C++ sacrificed memory-safety. Though it did add few features such as RAII in its latest updates which tackled manual memory management but it is futile as it doesn’t address the core issue.
Rust provides safer memory management as it does not allow null pointers and dangling pointers, and uses a system of ownership that enhances its memory safety by removing any ‘manual memory management’. It is more safe and secure with no harm to speed and performance.
|Memory Safety||No||Has built in features.|
|Ease of Use||Challenging. Could be a little complex to understand.||Easier. Well defined semantix.|
|Learning Curve||Hard to grasp.||Hard. But not as C++|
|Libraries||Standard Library. More general purpose. Its not framework driven.||It has frameworks like Azul and Nickel that provide robust and secure code|
|Game Development||Dominates the industry with its powerful frameworks.||Fairly new in this field. Framework isn't as powerful.|
Google Carbon vs Rust Language - Who Wins?
Carbon vs Rust, both show promise as C++ alternatives. For Carbon, we’re probably looking at a five-year development cycle until it’s released for production. While Rust is already there.
Both languages are (or will be) interoperable with C++ at a binary level. That implies that both of them could allow you to make gradual improvements to existing C++ programs by adding new non-C++ modules.
Carbon’s tooling will include automatic migration of C++ source code. An open question is whether that will migrate 100% of your C++ code, or require you to manually rewrite some percentage of your code that would otherwise perform badly, violate Carbon standards, or require you to mark it as unsafe should you want to leave it alone.
Rust already demonstrates memory safety. You literally can’t compile Rust code that will violate memory safety unless you mark it unsafe. Carbon will certainly implement memory safety mechanisms. We just don’t know yet exactly what they will be.
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. Infact, even the official Carbon documentation says, “If you can use Rust, ignore Carbon.”
But the problem with Rust is – Rust is difficult. It has a complex syntax and a steep learning curve. It is designed to uniquely solve some very challenging problems in programming. However, as a beginner, using Cuda or MPI on Rust is not very simple compared to the other options like Swift and Go. Moreover, it is slow. Rust is a snail compared to other languages. Even for small projects, the compile times are painfully long, and runtime measurements show that Rust is less efficient than the C programs.
Imagine rewriting C libraries that have had decades of scrutiny applied only to introduce new bugs. Bugs in code are programmers’ nightmare. While it does save developers from some mistakes, it does not stop them from unintentionally writing bugs. Another issue are the constant warnings appearing over parentheses, especially over if statements and while loops.
Rust is therefore a lot more complicated and inefficient and may soon be superseded by said tooling.
What makes Carbon better suitable than Rust is its introducer keywords and simple grammar. Carbon’s function input parameters are read-only values and the pointers provide indirect access & mutation. The writer can use expressions to name types and the package is the root namespace. The user can also import APIs through their package name. For Carbon, the explicit object parameter declares a method and it has a single inheritance. There are further benefits that extend beyond Carbon’s language, including ethical motives like the accessibility and inclusivity of the project’s culture.
Rust isn’t terribly easy to learn, even if you know C++, learning Rust is actually a little easier than learning C++ if you’re starting from scratch. Nevertheless, C++ and Go programmers usually manage to pick up Rust in a week or two.
Carbon’s C++ conversion tooling should enable a side-by-side editing tool, much like the IntelliJ support for learning Kotlin by converting existing Java code.
As you can see, both of them have their own share of pros and cons and it will be very early to get to any conclusion. Ultimately, we’re going to have to wait and see how each language and its tooling play out.
Every language has its own share of positives and negatives. Each language is created for a specific purpose and both Carbon vs Rust language have great future with their own scope and applications. Though who will ultimately win this battle will be decided by the future. BTW, who do you think has more chances of succeeding?
I hope this article must have given you some ideas about both the languages and their fundamental differences. If you are a company looking for developers to hire on remote basis, Optymize can help. We provide highly skilled pre-vetted developers to work on your development project. Take a look at our site or you can click here to hire.