C++ and Rust are both system programming languages that can be used to produce software and software platforms. They are both capable of interacting with low-level components such as operating systems or firmware on a microcontroller, or at a high level for application development.
Readers of this blog are most probably well familiar with C++, so needs no introduction. However, it may be interesting to look more closely at Rust, which according to StackOverflow surveys has been the most loved programming language for the past five years. Indeed, Rust is a hot topic at the moment!
Why Should We Compare C++ to Rust?
At this point, is there a point to comparing C++ to Rust? Is Rust intended to replace C++, or is it just a tool that makes low-level programming more accessible? With a growing ecosystem and community, and the lure of safer code, it is indeed worthwhile to compare Rust to C++.
One of the obvious questions is, which of these languages is better for enterprise? This is not an easy thing to answer, given that enterprise-grade software requires good marks in several aspects, including how well a solution is accepted and supported by the industry.
Why Rust?
Rust is often touted as a competitive language to C++, providing memory-safe functionality at compile-time, but without the use of a garbage collector as in other languages like Java or Go, thus enabling runtime determinism, low latency, and high throughput, as in C++. The challenge of manual memory management in C++ has long been seen as one of the biggest challenges for C++ developers, yet with only assembly code being closer to the hardware, C++ is blazingly fast. Rust offers similar low-level operations and high performance but has a safe mode to help squash memory bugs at compile-time before they become real problems in production.
Not only does Rust help prevent memory segmentation faults or leaks, but concurrency becomes easier because data races, where multiple threads try to access the same memory at the same time, are averted using the same compile-time protections.
So, if Rust is so good, why don’t we see a massive shift from C++ to Rust? Is there a catch? This is a flammable question. A “which language is better” discussion between C++ lovers and Rust evangelists can end up in a fistfight. And naturally, in such discussions, there isn’t any one right answer. Understanding the differences and what’s making each of the languages popular can help see the big picture and make an informed decision.
Rust Is Gaining Momentum (But Not Surprisingly, Still Lags Behind C++)
Although Rust is far from ubiquitous, there is now a Rust Foundation and several enterprise-level companies have begun to work with it to varying degrees. For example, Facebook has joined the Rust foundation, utilizing it in all aspects of development and committed to growing the Rust ecosystem; Google now supports using Rust to build the Android Operating System – the rationale being that it offers the power that comes with access to low-level system resources, yet provides memory safety guarantees that are superior to C++. Other Rust advocates include Mozilla, AWS, and Cloudflare.
Most enterprises that are using C++ and are now considering Rust are not going to throw away their C++ codebase, but rather explore in which areas Rust is going to be a better choice. The different forces behind the two languages inside a big corporation can be seen in Microsoft, for example. According to Rylan Levick of Microsoft, the company is moving away from C++ to Rust because of memory safety issues, and no longer considers C++ to be safe enough for mission-critical, infrastructure development. At the same time, Gabriel Dos Reis, Microsoft Principal Software Development Engineer said at a cppcast episode that Microsoft is and will remain C++ centric – Microsoft is experimenting with Rust, but as far as he is aware, currently, there is no shipping product being built with Rust. You can read more on Microsoft’s selection of Rust over Go and their experiments with Rust.
Another prominent figure expressing about C++ and Rust is Linus Torvalds, the creator of Linux. Those who follow Linus know that he is a C guy, known to be not so fond of C++, and that the Linux kernel is pure C (with some inline assembly). In an interview earlier this year, Linus said that there is an effort to evaluate the use of Rust as a supported language for developing the Linux kernel. As for C++, Linus sees it as a “crap language” that isn’t solving any of the C issues. This of course raised a fruitful discussion in Slashdot. More on Linus’ view of Rust can be found in another interview with him in ZDNet.
C++ Is Still King
Despite the undeniable popularity and interest in Rust, C++ is still dominant. In the TIOBE index for August 2021, C is still in the top spot while C++ sits in position #4, and as of the most recent index, Rust has moved from position #27 to position #24. A notable leap, of course, but it’s not exactly biting at the heels of C++.
When we look back at the origins and rise in popularity of C++, we recall that many developers made the transition from predecessor C mainly because of the Object-Oriented aspects that C++ brings, together with the strength of generic programming with templates and the richness of the standard library containers compared to the options provided by C.
Another aspect that cannot reasonably be argued is that C++ has an exceptional base of support. The C++ ecosystem is vast and at this point, with Rust being as young as it is, cannot complete in that regard. For example, Rust developers who are interested in game programming will find interesting resources available at Are we game yet? However, what they won’t find is anything nearly as mature as Unreal Engine 5 for C++. Simply put, if you’re trying to solve a problem in C++ then there are bound to have been many before you who tried to do exactly the same thing, so you’re more than likely to find a library for it. At this point, we’re not quite there with Rust.
It’s true that wider adoption of Rust will lead to wider use, new libraries, and frameworks, and the trend for Rust is probably up. But at the same time, more users bring new requirements, new features and changes to the language, which make the language become more complicated over time. Rust already has syntax options that are declared deprecated.
Rust, way below C++ in popularity ratings.
Source: https://www.tiobe.com/tiobe-index
Comparison
As always, the answer to most points of comparison will be “it depends,” because each varies based on the problem and implementation. However, there are certain trends that we try to capture in this point-by-point look at both languages.
Compiler and Platform Support for C++ and Rust
Both C++ and Rust are supported on multiple platforms including Windows 32 and 64-bit architectures, Mac, and Linux. Naturally, C++ has plenty more compilers than Rust. However, since Rust compiler is based on LLVM, it is supported in any environment that is supported by LLVM –a long list, including for example support for Rust in the realtime VxWorks environment. The Rust project defines three tiers of target support, where for the first tier the Rust project itself guarantees full certification. This kind of support is not guaranteed by the C++ standard committee, which doesn’t trouble itself with certifying compilers or providing a test bed for compilers. The C++ compiler vendors usually do a good job in complying with the C++ standard, but you may find minor glitches, especially when implementing new features of the language. As C++ is widely used, glitches in compiler implementation are usually reported and fixed quickly, especially if they are crucial.
The advice here is simple: don’t use Rust if your environment doesn’t support it, even though most relevant environments do.
Learning Curve and Speed of Development
Rust syntax and approach, the ownership model, the way Rust is implementing OOP, all are quite complicated for most Rust newbies, whether they are junior programmers or veterans of another language. The use of Rust is no different in that at the beginning, developers struggle with the syntax.
C++ is not an easy language either. However, most developers coming from C, Java, or C# find the basic syntax of C++ easier to understand.
That said, Rust programmers argue that after they go through the learning curve and control the syntax, they find Rust memory management and ownership model to be a boost to their development pace, eliminating errors with compilation errors on issues that would otherwise have been a runtime issue. C++ programmers on the other hand see the power given to the programmer as a good virtue, allowing you to express yourself without getting the language stopping you, leaving more responsibility to the programmer. Moreover, C++ programmers would argue that for the ownership model C++ provides unique_ptr and shared_ptr, while keeping much strength at the hand of the programmer. Rusters look at C++ smart pointers as a poor library-based solution compared to in-language support and enforcement of ownership. This, again, comes back to the argument of strict enforcement, which may have a steeper learning curve, compared to language options that are not mandatory.
Performance
Applications written in either language have the potential to perform well both in terms of latency and throughput, as they are low-level and operate close to the hardware. Both languages do not rely on a garbage collector, a fact which not only improves performance but also the predictability of runtime speed. Discord, for example, migrated one of their services from Go to Rust due to latency spikes that were being caused by memory issues and garbage collection.
There are competing benchmarks and talks on performance in favor of each of the languages. Anybody who deals with benchmarks knows that benchmarks might be controversial. But when you see many contradicting results, it usually means that both languages compete well and are a good fit for performance.
You can see a benchmark example here, and a summary of benchmarks here. The analysis at this blog post comparing C++ to Rust is also an interesting read, breaking some of the myths and diving into the question of performance differences between the two.
It is worthwhile to point out that when some specific optimization is required in Rust code, which breaks the ownership model, expert developers who are 100% confident in their error-free code may use Rust unsafe mode, where the memory safety net is cut. This is necessary in some cases, because Rust compiler, based on static code analysis, is rather conservative; in practice, the highest levels of optimization sometimes cannot be attained with it in place. In a way, Rust and C++ are taking the complexity of memory management in two different directions: while C++ keeps you unbound but allows you to use safe controls such as smart pointers, Rust goes with a more binding syntax that allows you (in the rare cases where the performance or other needs require that) to go `unsafe`. Both languages have the potential to have high-performance code, so it’s hard to tell whether there is a winner in performance in a general case. The answer is, as expected –it depends on the actual code.
Memory Safety
C++ has come a long way with the now-common use of smart pointers, although when you consider that Google has found that 70% of the serious security bugs in chrome were related to memory safety problems, C++ is considerably behind in this aspect. Conversely, the motivation behind Rust is memory safety. Essentially, to avoid the memory-safety vs. speed trade-off, C++ leaves memory safety to the developer, whereas Rust has inherent memory safety bounds that can be lifted with `unsafe` code. The Rust model for memory safety is a clear reason for selecting Rust, in case you feel memory safety is your problem in C++. As it seems, there are many C++ developers who argue – not without logic – that memory safety is not a significant challenge nowadays in C++, and even if it is a challenge, it doesn’t justify the cumbersome syntax of Rust as it is viewed by C++ lovers.
Pointers and Addresses
Both Rust and C++ have extensive support for pointers, and in both cases, the use of smart pointers is preferred. When it comes to using raw pointers, C++ developers primarily rely on manual code review and static code analysis tools to look for errors, whereas in Rust, raw pointers cannot be used outside of an unsafe block. Unsafe blocks are indeed the subject of manual review, although there are tools that can help you with that.
OOP
Despite the popularity and reliance on OOP, Rust does not support it in what might be considered the natural way. You cannot inherit structs in Rust, but you can implement a trait. You can achieve polymorphism in Rust through the implementation of traits and `dyn`, which is used on the entire trait, and affects all function calls on the sent object that implements this trait, making it dynamic. Rusters would argue that this is the right model for polymorphism and that data inheritance is not a real need because you can always rely on composition to reuse another type. Indeed, there is something clean in the way Rust lets you use polymorphism and in the clear separation between composition (“has a”) and type-interface (“is a”). Rust OOP model’s simplicity and purity are almost convincing, would say C++ programmer, till we reach Rust code that uses derive macros to imitate inheritance. Bottom line, Rust and C++ are different languages; you can always find things that you love in one and hate in the other, but it’s a matter of taste. It is important to note that both C++ and Rust have many programmers that really love them (and quite often hate the other), so you cannot say that any of the two is bad.
Concurrency
Concurrency in C++ is fast and robust, and there are many libraries available for C++ multi-threading including the C++ Standard Library and Boost. When it comes to thread safety, however, the memory safety features of Rust help prevent concurrency-related issues such as data races. Data races are arguably the worst type of concurrency bugs: easy to create and hard to locate. The Rust model, however, would make it harder for you to share data while making sure that you are not creating a data race. C++ programmers who are confident in their code may find the restrictions of Rust too binding in implementing multi-threaded applications. Rust programmers would argue that those confident programmers are those they fear the most: having the safe checks of the language is required especially for them, even if that means that they would have to change the way they share data between threads.
Community Support
Both languages have evolved through a very controlled and managed process, C++ via the C++ ISO Committee and Rust via the Rust Foundation. Both have a very active community. That said, Rust, being quite young compared to C++, is difficult to compare against the much larger base of its counterpart. C++ has many more forums, open-source projects, and StackOverflow contributors. The reality is that C++ has been around for so long that the odds of a developer uniquely coming across an issue are astronomically low.
An example of the difference of community support might be by comparing two similar open sources, one in C++ and the other in Rust. Beam is an open-source cryptocurrency project written in C++, implementing the Mimblewimble blockchain protocol. Grin is another implementation for the same protocol in Rust. Both came out around the same time, in early 2019. Although they were created by different groups, they’re being open-sourced means that their evolution and progress rely on community support. But as shown in the charts, the support obtained by the C++ project, Beam, is much larger than that of the Rust project, Grin.
Below, Grin – written in Rust, commit activity in the last year.
Source: https://github.com/mimblewimble/grin/graphs/commit-activity
Below, Beam – written in C++, commit activity in the last year.
Source: https://github.com/BeamMW/beam/graphs/commit-activity
External Libraries
Both C++ and Rust have myriad frameworks and libraries to work with. Despite the age gap, Rust already has a vast library selection to help with web development, game development, operating system development, blockchain, and more. C++ of course has its own huge selection of libraries (click here to read about the top C++ libraries). Both have active and contributing supporters and it seems that you would usually find commonly needed functionality already implemented for either of the two.
Package Management and Tooling
Another thing that developers like about Rust is package management. Cargo is the official Rust package manager, and it is not dissimilar to what developers use in Python or JavaScript. While C++ has some good package managers available, such as Conan, developers point out that they are not as easy to use as Cargo. In general, for a language as young as Rust, the set of tools that come with it is impressive and competitive to C++. Although C++ was a bit lagging in raising a good toolset for developers, it is finally starting to close the gap of supporting tools.
Which Is Better for Enterprise?
At this point, the question of which is better for enterprise will be dictated by what is being developed, and the team’s experience. The 2020 Rust Survey has some interesting and relevant facts, including that 40% of respondents use it at work to some degree. Coupled with the knowledge that several aforementioned enterprise-level companies already use it, it certainly cannot be dismissed. That said, respondents still complain heavily about a steep learning curve, a need for better training and documentation (a bit surprising, as Rust does have great documentation), a lack of needed libraries, and the time and effort required to make the full transition to Rust.
It makes sense that if more Rust programmers were available for hire, it might make serious inroads into enterprise on a more general level. To this point, the largest change in Rust users this year appears to be an increase in the number of students learning or using Rust. If this is indeed representative of the community at large, then we can expect more Rusters to be available for hire in the future. At the same time, we must remember that currently there are much much more C++ lines of code to maintain, compared to Rust, and much more C++ programmers out there.
In Conclusion…
C++ and Rust are system programming languages with a good following and community support. Each has its advantages and disadvantages, making it very probable that we will see both stick around for a long time. The question remains: will C++ continue to rule, with some peripheral use of Rust, or would C++ lose significant market share to Rust?
At this point, it is probably too early to tell. The 2020 Rust Survey points to several areas where Rust has improved and gained popularity over the past year. However, with C++20 published and C++23 under development, rest assured that C++ is not going anywhere. At least not for now.
Should enterprise get ready for Rust? Certainly, there will be projects that could benefit from it. Is it necessary to consider using Rust over C++? Not likely at this point. In this race, neither is going to stop improving and if better interoperability between the two comes to fruition, there may be a very long relationship of cooperation and respect ahead.
Additional Reading
A nice comparison of Rust and C++, focusing on syntax differences:
https://www.apriorit.com/dev-blog/520-rust-vs-c-comparison
Reddit discussion on Rust vs. C++:
https://www.reddit.com/r/cpp/comments/611811/have_you_used_rust_do_you_prefer_it_over_modern_c
A similar discussion in ycombinator:
https://news.ycombinator.com/item?id=24037045
Industries using Rust vs. C++:
https://www.efinancialcareers.co.uk/news/2020/09/rust-vs-c-hedge-fund-jobs
Companies using Rust:
https://serokell.io/blog/rust-companies
