Is it time to retire C and C++ for Rust in new programs?
- Reference: 1664353810
- News link: https://www.theregister.co.uk/2022/09/28/is_it_time_to_retire_c/
- Source link:
Mark Russinovich, [1]Microsoft Azure's CTO, tweeted that "it's time to [2]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!
[3]
What prompted this? As noted [4]here , it's not really a desire to start another endless [5]programming language war – see vi vs EMACS, tabs vs spaces, and Java vs Python. No, I think what sparked his comment was that [6]Linus Torvalds has given his blessing to bring Rust code into the Linux kernel , starting with Linux 6.1.
[7]
[8]
If the Linux kernel developers, the programmers of the most successful C project of all time, are embracing Rust, why not the author of [9]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 [10]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."
[11]
He's right, of course. When I first started programming, everyone said COBOL was history. Forty years later, [12]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.
[13]Rust is eating into our systems, and it's a good thing
[14]Linus Torvalds predicts Linux Kernel 6.0 debut next week, dispels fear of delays
[15]In Rust We Trust: Microsoft Azure CTO shuns C and C++
[16]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 [17]SEI CERT C or use more secure guidelines in working with a language such as the [18]C++ Core Guidelines . And, as Bjarne Stroustrup, C++'s creator, told The Register recently: "We can now [19]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: " [20]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."
[21]
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 [22]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. ®
Get our [23]Tech Resources
[1] https://azure.microsoft.com/en-us/
[2] https://twitter.com/markrussinovich/status/1571995117233504257
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YzQbPleJG0CIHyQEC0x2mwAAANA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://www.theregister.com/2022/09/26/rust_column/?td=rt-3a
[5] https://www.theregister.co.uk/2022/09/28/is_it_time_to_retire_c/
[6] https://www.theregister.com/2022/09/16/rust_in_the_linux_kernel/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YzQbPleJG0CIHyQEC0x2mwAAANA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YzQbPleJG0CIHyQEC0x2mwAAANA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] https://learn.microsoft.com/en-us/sysinternals/
[10] https://twitter.com/markrussinovich/status/1572619885083230208
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YzQbPleJG0CIHyQEC0x2mwAAANA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[12] https://www.nytimes.com/2022/07/06/technology/cobol-jobs.html
[13] https://www.theregister.com/2022/09/26/rust_column/
[14] https://www.theregister.com/2022/09/26/linux_6_rc7/
[15] https://www.theregister.com/2022/09/20/rust_microsoft_c/
[16] https://www.theregister.com/2022/09/16/rust_in_the_linux_kernel/
[17] https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard
[18] https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
[19] https://www.theregister.com/2022/09/20/rust_microsoft_c/
[20] https://www.cprogramming.com/tutorial/memory_debugging_parallel_inspector.html
[21] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YzQbPleJG0CIHyQEC0x2mwAAANA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[22] https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/
[23] https://whitepapers.theregister.com/
Re: "in our copious free time"
There is a reason that I write it "My !copious free time" ...
C/C++ - really?
Ok I'll bite.
I need to point out, that anyone lumping C together with C++ is off the rails to begin with. C++ was made to make things possible that were not realistically possible in C, it accomplishes this by significantly extending - and to a smaller extent changing - the syntax and semantics of the C language. These are two different languages that solve two different problems; anyone writing "C/C++" must have missed this point - and if you miss that point, I'm not really sure how any opinion that person may have on languages, especially those languages, would be relevant.
C++ solves a number of real world problems; and we can always have an argument about how well it does that - clearly with the legacy of C compatibility the syntax of C++ may not be as it would have been, had the language started from a clean slate with not a care for compatibility and adoption.
Rust set out to also solve some problems, and that's great. One of the most notable problems in my view, that C++ solves to a high degree and which Rust doesn't even attempt to solve, is that of reliable error handling. Rust encourages a coding style where errors are ignored, because passing back errors via return values is tedious and leads to boilerplate code. Yes Rust tries to help you remember this with compiler enforcement, but nobody likes boilerplate code and the language encourages you to circumvent this mechanism.
In contrast C++ solves this with exceptions (which is by no means something C++ invented), which again comes with its own set of requirements for competently written code. C++ offers all necessary mechanisms to safely handle errors in large scale applications without the use of boilerplate code - and I personally find that to be a huge advantage over languages that do not (such as Rust and many others).
This is not to say that you can't write good software in Rust; of course you can. Lots of great software is written in C too. And I'm sure Rust is a slightly better C than C for many uses - and that's great. I'm not trying to detract from Rust here.
But honestly, replacing C++ with Rust for large scale applications that need to work in the real world? Sure you can do it. Given enough investment anything is possible - I have to say I don't see this happening on a large scale for business that actually need their software to work all the time and every time.
Re: C/C++ - really?
During the meanwhile, there is a reason that kernels and similar close-to-the-hardware stuff (so-called "drivers", for example) is usually written in C and/or assembler.
There is no one size fits all for software development. Anybody who tries to tell you otherwise is deluded.
Horses for courses & all that.
Re: C/C++ - really?
Maybe Stroustrup can cook up Rust++.
Thank you for your contribution to the evidence supporting Betteridge's Law of Headlines.
Wait a minute ...
We should take the advice of someone who will look you straight in the eye and tell you "Windows is a GREAT operating system!"?
Somehow I don't think this will fly with the cognizant.
C++'s most powerful feature is that it can directly consume C headers. It is not a mathematical superset of C but in practice 99.999% of stuff just compiles and works (or can be tweaked) and that is all that matters.
Rust will beat C++ once it can consume C headers directly without needing bindings. FFI, like JNI is time consuming and error prone. The bindings created tend to rot because they cover the entire API so are very fragile to breakage in a tiny area you might never even use. Creates.io is a lazy solution to an unnecessary problem that can instead be avoided by just using a homogenous language in your projects.
This is simply no good. Legacy code will not be rewritten, people will continue to use C for libraries because they can be wrapped by all languages.
If C++ *needs* to be replaced, then CppFront, Carbon, heck even Objective-C++ would be where I would place my bets. In the industry, changes need to be evolutionary rather than wasting our time rewriting stuff that has already been solved.
Mark Russinovich knows this, he is just being a twat.
Don't code [throw away and fast] fashion
[programming...] It's just that it has never, ever been easy.
An that is the point. Programming is hard. Period.
You should use the language suited for the job at hand. Not go into the whole this or that is better/worse fight. The hype is that we "should replace" a language. That is the wrong premise. It is mentioned, a language must apparently be "sexy". Well, 25 years ago, suddenly everything just had to be done in java, regardless whether it made sense or not. We see the same hype today.
Again, we should use the programming language suited for the job at hand. And, never ever forget, you need a good programmer because programming is hard!
Complier support
The biggest concerns I had last time I looked (which is a while ago now) are the lack of qualified compilers (for the safety community), and support for a diverse range of micro-controllers.
Has this changed?
Edited to correct a typo
Real programmers
C was designed and implemented for real programmers: competent people who know what they are doing and take the trouble to do it properly. As opposed to the two disasters of modern coding: the contractor fixated on "productivity" and getting paid; and the "free software" types who rely on the "thousand eyes" of users and other programmers to fix their bugs.
Rust merely makes the latter two evils slightly less worse.
Re: Real programmers
Totally agree
I write C code on a daily basis. Yes, I sometimes find a bug and I correct it. But I can’t remember the last time I had a bug caused by memory corruption, bad pointers or running off the end of an array. These are schoolboy errors - if you’re competent and disciplined enough, you just don’t do this sort of thing.
C seems to get a lot of flack from people who are clearly not competent enough to use it.
"in our copious free time"
That's a good one :)