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:Bullshit slashvertisement

[Kohath]

This is a common argument. What you're really saying is that a small number of elite developers feeling good about themselves is better than good tools that prevent mistakes.

And the response is "No, it's not." We need more people to be able to produce more with fewer mistakes. The number of developers who write production code will always be more than the number of developers who write mistake-free code. The way to get more mistake-free code is to eliminate opportunities to make mistakes.

Shorter version: "We're trying to accomplish a goal. It's not all about you."

ATTENTION RUST CODERS: You are all stupid faggots

[Anonymous Coward]

Holy fucking $&!<:' worst delimiters EVER CHOSEN. It's like a hyperactive aspie found a way to marry to the worst aspects of C++ templates, Visual Basic, PERL and Brainfuck.

pub struct DeclarationListParser<'i: 't, 't: 'a, 'a, P> { /// The input given to `DeclarationListParser::new`
    pub input: &'a mut Parser<'i, 't>, /// The parser given to `DeclarationListParser::new`
    pub parser: P,
}

This is how you do ($string == "!important") in faggotass Rust:

/// Parse `!important`. /// /// Typical usage is `input.try(parse_important).is_ok()` /// at the end of a `DeclarationParser::parse_value` implementation.
pub fn parse_important(input: &mut Parser) -> Result<(), ()> {
    try!(input.expect_delim('!'));
    input.expect_ident_matching("important")
}

Formal verification is not so unrealistic

[Anonymous Brave Guy]

That seems to be a very defeatist attitude. Formal verification doesn't need to be a huge burden. After all, we enforce many useful properties of our programs automatically all the time just by using strongly typed languages. (Obviously less so with needlessly dangerous languages like C and C++, which seems to be the fundamental point in this particular discussion.)

It's true that it might be prohibitively expensive to formally prove every conceivably useful property of every line of code using the best known methods. Indeed, just figuring out how to specify exactly what you do want to prove isn't always straightforward.

However, this isn't a black and white issue. We could do much better than we actually do in everyday software development, and the savings could be substantial. The fact that we don't use more powerful tools and more powerful methods routinely is more down to some mix of developer ignorance and hubris than anything else. Most working developers probably don't even realise what is possible or know roughly how the tools and processes work, because unfortunately this remains a relatively low profile field for now. Too many working developers would rather just play with the latest libraries that came out this week in their painting-by-numbers languages anyway, or listen to consultants who've never written a piece of critical software in their entire careers offering the false promise of good code without having to spend much time on things like proper design or documentation.

We could do so much better with even a modest investment in developer education and a willingness of management to look beyond the current quarter's accounts. Ironically, given the savings from better quality code both due to lower maintenance costs generally and particularly in areas like security or regulatory compliance where failures might also have $$$ fines attached, it might even work out cheaper in the long term to develop in a more careful, considered way. Just some robust analysis of the different possible cases and data flows and so on would probably turn up all kinds of lurking bugs in everyday software, and this is hardly beyond the abilities of an average developer if they have some awareness of what is possible.

Now, if our priority is to build throwaway web/mobile startups that can TDD an MVP in ten seconds and don't care much about long term maintenance or quality because they're going to either flip or fold the business within a year or two anyway, or if we're interested in in-house business admin systems that need to be as cheap as possible right now because it will come from someone else's budget if we have to fix any screw-ups later, none of this matters. But if we actually want to build good software, then at some point we have to start playing the long game and looking at options that aren't the quick, easy path all the time.

Re:Yes, go ahead!

[Anonymous Coward]

If developers can't write secure programs using C what makes anyone think they can do it using Rust or any other language for that matter? One of the reason the author would support Rust over C is that C gives the programmer to much access to the underlying OS and hardware layers and creating security issues. There is a quick and surefire way to alleviate this concern. Hire people that know what the are actually doing. Assigning your front-end web developer guru to a project that requires C skills is just asking for trouble. Developers are quite adept at taking any language on any platform and creating some really impressive security holes that have nothing to do with the particular technology being used. And if you refactor your C code one piece at a time you now have two different development environments to support for however long it takes to retire all the C code. Of course this assumes you can find enough competent C/C++ developers willing to work on such a project. The largest segment of the software developer talent pool is programmers who develop against runtimes (usually built using C/C++ or Java) instead of programming against an actual OS. The next greatest segment are the programmers who maybe knowledgeable in all the various scripting technologies but haven't a clue about the under lying scripting engines that turn their scripts into an actual program. If you pitched this conversion project to me the first thing I would ask is what are the actual real world benefits of replacing C with Rust.