This article is more than 1 year old
Is it time to retire C and C++ for Rust in new programs?
Mark Russinovich, Microsoft Azure CTO, thinks so
Column We all know that the Rust language has become much more popular. By Slashdata's count, Rust users have nearly tripled in the past 24 months.
Mark Russinovich, Microsoft Azure's CTO, tweeted that "it's time to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required. For the sake of security and reliability. The industry should declare those languages as deprecated."
Them's fighting words!
What prompted this? As noted here, it's not really a desire to start another endless programming language war – see vi vs EMACS, tabs vs spaces, and Java vs Python. No, I think what sparked his comment was that Linus Torvalds has given his blessing to bring Rust code into the Linux kernel, starting with Linux 6.1.
If the Linux kernel developers, the programmers of the most successful C project of all time, are embracing Rust, why not the author of Windows Sysinternal Tools?
Mind you, Russinovich isn't suggesting that we trash everything already written in C or C++ and rewrite it in Rust in our copious free time. Far from it. As he tweeted after he challenged the industry to say goodbye to C and C++: "There is an enormous amount of C/C++ that will be maintained and evolve for decades (or longer). Last night I coded a feature for Handle, adding to the roughly 85,000 lines of Sysinternals C/C++ code I've written. That said, I'll bias towards Rust for new tools."
He's right, of course. When I first started programming, everyone said COBOL was history. Forty years later, COBOL is alive and well, and its programmers are still raking in the money. So there!
Languages never die. They just stop being sexy.
That said, there are excellent reasons to retire C and C++ in favor of Rust. First, Rust was designed with performance and safety in mind. The C family is all about speed and more speed. Security came a long way second.
- Rust is eating into our systems, and it's a good thing
- Linus Torvalds predicts Linux Kernel 6.0 debut next week, dispels fear of delays
- In Rust We Trust: Microsoft Azure CTO shuns C and C++
- Linux luminaries discuss efforts to bring Rust to the kernel
True, you can write securely in C or C++. For example, you can use a more secure language variant such as SEI CERT C or use more secure guidelines in working with a language such as the C++ Core Guidelines. And, as Bjarne Stroustrup, C++'s creator, told The Register recently: "We can now achieve guaranteed perfect type and memory safety in ISO C++."
Indeed, you could always write perfectly secure C and C++ code. It's just that it has never, ever been easy. Both languages make it much too easy to make memory errors. They include Invalid heap and stack memory access; memory leaks; mismatched memory allocation and deallocation; and uninitialized memory access. And those are just the common blunders I've made! As Naveen Gv, an Intel technical consulting engineer, put it: "Memory errors occur very commonly in C and C++ applications, and … can be hard to reproduce, hard to debug, and potentially expensive to correct as well."
Both languages are "memory-unsafe." They give developers fine-grained control of their application's memory, but with great power comes great potential for trouble. One memory snowball slip-up can lead to an avalanche of errors.
These aren't just theoretical errors. They happen all the time. In 2019, Microsoft confessed that 70 percent of its Common Vulnerabilities and Exposures (CVE) security problems had been caused by developers making memory corruption mistakes in their C and C++ code.
As much as I like to make fun of Microsoft security, this problem is far from unique to Microsoft. Google's developers have found the same percentage of memory problems in its Chromium/Chrome web browser code. I'm sure it's that bad in pretty much everything written in C or C++.
Rust, on the other hand, is a memory-safe language. Sure, you can still make security blunders with it. You can in any language. But, and this is the important part, it's much harder to make the kind of simple memory missteps that bedevil C and C++ applications.
That's why, years before Rust started making headlines, Google and Microsoft both started considering replacing C and C++ with Rust. Now Linux is embracing Rust as well.
Besides security, Rust has the advantage of making it easier to write concurrent programs. Rust was written for a world with containers and the cloud, while C was written for 16-bit DEC PDP-11 minicomputers. Now, both C and C++ are very flexible, but we're a long way from single processor/single core computers!
That said, Rust won't replace its older brothers tomorrow. It will take years – indeed decades – but it will happen. We've ignored security for generations, but now that our entire economy depends on secure technology, we can't afford to be so cavalier with our programs. ®