Being at a point where I have the luxury of time, I'm considering investing some in Rust. For context, I'm a C++ dev with 10+ years of experience and this move was prompted by observing two indicators: StackOverflow's survey stats showing a consistent positive trend in user preference and, more recently, an increasing number of positions for Rust or in combo with C++.
The following is a quick dive into C++ pitfalls and how Rust fills the gaps, corporate backing and interests, institutional interference, ending with the question of whether one should be joining the growing sea of rustaceans.
Usage metrics
The StackOverflow 2024 stats indicate a significant user preference loss for top languages (C++, C, C#, Java, TS, JS and Python) compared to 2023, 2022, 2021 and 2020. All, except for Rust, whose percentage almost doubled. The gap is so intriguing that makes my thick eyebrows frown.
It must be pointed out that StackOverflow's result representation has changed in 2024, indicating two percentages per entry instead of just one. The only category that still follows the curves of previous years is the desired category, the other (admired) being too far off. Averaging the two still doesn't yield results following the trends. For the remainder of this article, I'll be assuming StackOverflow's impartiality and that their new process didn't affect the results.
For the sake of this argument I went ahead and checked this on Google trends, and the results were surprisingly different: Rust reached 2% sometime in 2022 and then remained constant at that value. Their results were so questionable that I chose to ignore them.
Further research led to the Statista survey for 2024. However, their data seems too similar to the StackOverflow stats for 2023: same question, slightly different number of responses and almost identical percentages per technology.
Although I would understand reusing publicly available data, I refuse to accept 2023 values presented as 2024 stats. Anyway, that should be a matter between StackOverflow and Statista. Given my doubts, I choose to ignore these results as well.
Being a huge asset in the software developer community and knowing their survey for years, I'm inclined towards StackOverflow's aggregated data. In fact, I have no choice.
So, what could have generated this abrupt shift in preferences? Other programming languages have appeared before (eg. Java in the 90s) but grew organically in developer use. Rust seems unlike any other in terms of ascension recently and that's intriguing.
The interference
Last year I was reading an article about NSA's recommendations on programming languages (Cybersecurity Information Sheet on Software Memory Safety) by which it was suggested a "strategic shift from ... C/C++" for memory safety reasons. I was giggling on the fact that backward compatibility, the immutable characteristic of C++, meant it's still possible to compile calls to gets() on a C string. Reactions were not vehement for the same reason until Bjarne Stroustrup's held a speech in defense of modern C++, separating it from C and reiterating the obvious: can't have C++ without the messy low-level stuff.
Then, in February 2024, the White House issued another document
BACK TO THE BUILDING BLOCKS: A PATH TOWARD SECURE AND MEASURABLE SOFTWARE
plainly stating that C and C++ [...] are not memory safe, followed by the suggestion for Rust as an alternative, quoting security reports by Microsoft, Google and following on an expert article which concluded that Rust is one "fantastic alternative to C and C++".
Thus, a sudden popularity boost for Rust.
Back to C++
C++ backward compatibility guarantees decades old code compiles today but also permits writing 90s style code, in total disregard with the most recent C++ standards and their safety improvements. Temptation is high: books published in the 90s can still be found in libraries, old examples are plenty and the modern C++ syntax is repulsive. Making matters worse, the subsequent standards added more features but also new (again, type safe) ways of achieving the same goal, at the cost of the overall language orthogonality. The result: new developers lean into shortcuts, learning C++ the bad way.
A significant improvement can be achieved simply by using standard libraries, following recommended coding guidelines, using a static analyzer (though limited) and memory checker tools (eg. valgrind) but the problem is that none of these can be enforced.
In contrast, Rust was designed to be safe by default. The ownership and reference borrowing rules elegantly address the memory safety, match control flow prevents unhandled known branches and all these are compile-time checks. There's a price to pay, however, as circular dependencies are not possible with this model and the implementation of complex memory graphs isn't an easy task either, leaving two choices: circumvent the safety or use external crates (that eventually do so). The latter leads to more code delegation, with the good and the bad.
Solutions for C++
To tick the safety issue, compilers need to have options to enforce certain rules, for instance forbid features below a standard. One milestone from which the language can be considered safe is C++11, colloquially known as modern C++. It contains important library features, most notably the memory model facilitating portable threading. A more practical language is C++14, or better still C++17, but hey, safety first.
But, there's a problem with that...
A systems language is useless without ways to access the hardware or the OS; a program still needs the dangerous features of C or C++ to achieve anything meaningful.
Bjarne Stroustup promotes something more generic, coined static safety profiles. This idea originated from Ada and tunes the compiler to perform additional compile-timer and/or run-time safety checks depending on the application. They represent a set of requirements and constraints applicable by domain. Hopefully, this will be standardized soon considering the pressing safety issue (standard committee's process cycle measures in years) and included in C++26.
Although not addressing the problem per-se, I like the fresh C++ syntax 2 (or cppfront) proposed by Herb Sutter. It is safer, a lot nicer to read (compared with modern C++ and even with Rust) and it doesn't have to obey the backward compatibility restriction. This resembles the way C++ spun off C. It still feels toyish and far from maturity but I personally like this approach and would like to see it getting more traction.
My rant
C++ doesn't have a generally agreed-upon standard for managing project dependencies. A preference among linux developers, myself included, is CMake but that is nowhere near as simple as the Rust's cargo. In fact, the two cannot even be compared as CMake is another language in its own right with a pretty steep learning curve. Alternative tools can be custom built to tackle the challenges but those overwhelmed by the complexity give into proprietary solutions and never look back. An attempt at managing and centralizing packages npm-style is conan.io, which evolved quite a lot in the past years in terms of functionality, community and documentation. However, it is not catching-up among the devs and companies I know of. In fact, every project I contributed to followed religiously their own favorite build and dependency tooling.
Error management is another delicate, partly unsolved issue. The 1998 standard brought exceptions, a wedge that divided the C++ community. There are some, like Google, that steered clear of them. Can't blame them. Because standard library containers and streams use them, you're either forced to write your own or get in the exceptions bandwagon. As soon as you choose the latter you find that there's a fine balance in handling them properly and most often than not, they're the proverbial shot in the foot. The P0003R0 open-std paper provides a glimpse of the long debate on exceptions and underlines the importance of due process in standard committee decisions. Once in standard it cannot be removed without breaking the backward compatibility and the effects could only be alleviated with inherent negative effects on language expressiveness and/or orthogonality.
Lastly, the standard committee process is slow. That's a known bug/feature. Everything is prioritized and there's so much that can be put through in a standard approval cycle, leaving way too many things behind. Though it has improved recently, historically this led to divergence. Think about the name mangling differences between compilers. One other effect of a language's age is the multitude of coding styles, each with their musts, must-nots, recommendations, etc. There's the Microsoft way, the Google way, the Mozilla way, the GNU standard, LLVM has its own and, as if there aren't enough, most companies have theirs. Likewise, there's a myriad of libraries, proprietary or open-source static analyzers and tools that drive the novice into confusion and away for C++. One good thing that came out of this is the number of compilers, some of which are open source.
What about Rust?
It appeared after subsequent generations of software lessons were learned the hard way and got to cherry-pick the best features of all. Considering its age, it doesn't have the backward compatibility issue (yet). It's got a complete development ecosystem: its own package management, a nice documentation tool and an excellent documentation. It has a compiler so stubborn that just wont pass on crap, yet verbose enough to point in the right direction. That also eliminates the need for 3rd party code analysis tools. Nice!
Just like C++, a Rust program often needs to perform low-level operations, whether via external modules or by itself. Considering the known limitations of safe Rust, I'd be interested to know how many crates and programs actually use the unsafe keyword to achieve their goals and how different that is from the unsafe C or C++ features. The fact that embedded manufacturers (eg. Espressif) or OS kernels (such as Linux) offer or are progressing towards Rust, is a good indication of safety gains. However, the existing low-level code cannot be changed overnight or without considerable resources and risks. Time will tell if the effort actually payed of.
One thing is sure: Rust is the new kid on the block, the knight in rust...sorry, shiny armor. Anyway, it seems everyone's favorite. Besides the great features, it is pretty well marketed: nice website, cute logo and a name for its developers. Yeah, Rust developers are rustaceans. How cool is that?! I, of all people, know a systems programmer despises one's reflection to be self-entitling anything. Gotta say, that's well thought of.
So, who's backing Rust? Well, all the big tech companies I could name are founding members of the language. I'm not aware of each one's contribution to the project but certainly there's something to be gained from this on the medium-long term beyond safety guarantees. A more homogeneous developer pool, maybe?
Will I invest in Rust? By all metrics, it's worth a try without high expectations in terms of performance or safety improvements compared to modern C++. Again, I speak as a well versed C++ developer. Personally, I'm a bit uneasy about the recent preference boost, the backing companies and the institutional interference. One reassuring thing about Rust is the transparent RFC language governance, although I'm not sure if it will be faster than WG21 in feature adoption. Anyway, the shift in trends towards Rust could continue for the next years or at least until the safety issue the C++ inherits is addressed.
Finally, I believe Rust will fill gaps in or around C++ and will coexist with the latter. If anything, it will erode the market-share of all major languages, but will not replace any and especially not C++.