TechCrunch Urges Developers: Replace C Code With Rust (techcrunch.com)

Software engineer and TechCrunch columnist Jon Evans writes that the C programming language "gives its users far too much artillery with which to shoot their feet off" and is "no longer suitable for the world which C has built." An anonymous reader shared Evans' post: Copious experience has taught us all, the hard way, that it is very difficult, verging on "basically impossible," to write extensive amounts of C code that is not riddled with security holes. As I wrote two years ago, in my first Death To C piece... "Buffer overflows and dangling pointers lead to catastrophic security holes, again and again and again, just like yesteryear, just like all the years of yore. We cannot afford its gargantuan, gaping security blind spots any more. It's long past time to retire and replace it with another language.

"The trouble is, most modern languages don't even try to replace C... They're not good at the thing C does best: getting down to the bare metal and working at mach speed." Today I am seriously suggesting that when engineers refactor existing C code, especially parsers and other input handlers, they replace it -- slowly, bit by bit -- with Rust... we are only going to dig ourselves out of our giant collective security hole iteratively, one shovelful of better code and better tooling at a time."
He also suggests other fixes -- like using a language-theoretic approach which conceptualizes valid inputs as their own formal language, and formal verification of the correctness of algorithms. But he still insists that "C has become a monster" -- and that we must start replacing it with Rust.

Comments

Re:An embarrassing admission

[Anonymous Coward]

While in grad school I had a roommate take an introductory to programming course. I saw grave errors in the example code the lecturer was giving the students. It starts with the education. If they are not taught properly from the beginning don't expect anything but crap later.

In the basic read stuff from a file example given to the students -

char c;
while ( (c=getc)!=-1) {
}

Fix the code dont try a new language

[gordona]

How about training developers on security policy, training mgmt on the need for secure code and the balance between acceptible risk and convenience, proper requirement and tests.

Re:What happens to Rust when Mozilla is gone?

[AaronW]

I agree. If Firefox or Thunderbird is anything to go by I'd stay far away. I used Thunderbird for years until very recently but its performance is unusably bad. On my quad core xeon workstation it's almost impossible to write email because the editor freezes so frequently, often for seconds at a time. In the process it drops characters so I can't even type ahead. I suspect it's due to its single threaded nature and I'm dealing with several IMAP accounts with a LOT of emails. I recently switched over to KMail which seems to work far more smoothly. On top of that, Thunderbird is a huge memory pig. I gave up on Firefox ages ago and switched to Chrome due to horrible performance with single-threaded Javascript and the fact that it leaked memory like crazy for years. I also blame Mozilla for killing off MNG which is why we so often are STILL stuck with gif, which is a horrible format for most of the animations I see.

Rust has its place but it isn't going to replace C any time soon. There are other languages that also make the same claims, i.e. Go, Swift, D, etc.

One thing about C is it is supported on virtually everything except the micros where only assembly or some oddball language is the only thing supported (I used a processor that ran a pattern matching functional programming language at the hardware level once). There are plenty of other languages that are better than C in many cases, but one thing with C is you don't need to worry about libraries having weird interactions with other languages. C bindings are ubiquitous and very well understood and supported. C++ apps can easily link to and call C libraries but the other direction often requires some glue logic. Most languages can link against C code whereas the opposite is often not true. C has very minimal underlying requirements. I have written numerous bootloaders in C which require only around a page (or less) of assembly code. By boot loader, I'm talking about with no BIOS underneath for embedded systems. Cross compiling is well supported as well and I frequently am cross compiling for MIPS or AARCH64 with compilers that are tuned to the specific chips they're targeting.

I'm playing with an ESP32 device right now which has two Xtensia cores in it. No Rust support but C and C++ are both supported. There's no underlying operating system. Similarly, one doesn't run Rust on Arduino platforms. Rust is tied almost exclusively to LLVM. There is no GCC support for Rust so there are plenty of platforms where Rust just isn't supported.

C and C++ are supported by many toolchains, both open source and proprietary. Rust is not.

Re:Yes, go ahead!

[AaronW]

Rust is not all that portable. Rust is tied to LLVM. There are a lot more platforms supported by, say, GCC than LLVM. For example, I'm working on some Arduino and Xtensa based stuff at the moment. No Rust support but C and C++ are both supported. It's also trivial to link between C and assembly or for that matter C and just about any other language. I mix C and assembly all the time in the work that I do. I don't need any overhead of garbage collection, bounds checking, etc. either. The C calling ABI is very well documented and supported on all but the lowest end microcontrollers. If I write a library in C, it can be called from virtually any language. If I write a language in Rust, i doubt that would be the case. The C runtime library is pretty trivial. I've written bootloaders with only a page of assembly before calling the main function. By bootloader I'm referring to a true bootloader, code that is the first code executed when a CPU comes out of reset, not something called by the BIOS but code that will at some point load the BIOS.

Re: Yes, go ahead!

[TheRaven64]

I work with a group that does formal verification and you seem also to be talking from a position of ignorance. Currently, the record for low-cost formally verified software is held by the NICTA team behind seL4. Their number is around 30 times the cost of using best practices for normal software development. A few caveats for this number:

• The baseline is assuming the effort involved in creating a test suite with full coverage of the specification and a detailed specification. Few projects actually have this level of QA, so add another factor of 2-4 to the cost relative to most projects.
• They're employing mathematicians on fairly low (academic-level) salaries for the verification. In an industrial setting, with skills in so much demand, you'd find it difficult to pay them less than double this.
• Their entire software stack is around 10,000 lines of code and they've not yet shown that their verification effort scales linearly with the complexity of the software.
• The cost of refactoring is close to the cost of initial development, as the proofs are not often reusable after modifications to the code.
• It was a whole 6 hours between the first public release of their formally verified microkernel and someone finding the first exploitable security vulnerability.

There's a lot of ongoing research in this area (I quite like F*, though it has some significant issues with proof reuse and usability of its error messages), but the tools for formal verification are currently as appropriate for large-scale modern software development as punch cards.

Re:Yes, go ahead!

[TheRaven64]

Except that Rust is kinda a bit like C except with a formal verifier built in so you can prove you don't have memory errors

Please stop repeating this. Rust has a type checker. Most languages have a type checker. The type system in Rust is stricter than that in C (though it is possible to implement the same thing in the library in C++), but it is not a formally verified type system and the implementation of the type checker (which is not a formal verifier) is also not verified (and can't be until the type system itself is verified). If you want a language with a formally verified type system, look at Pony. If you want a language that integrates formal verification, look at F*. If you want to use Rust, that's fine, but stop claiming that it has features that it doesn't.