Slashdot Mirror
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.
"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.
Yes, replace billions of working C code with billions of lines of code in a new language. What could possibly go wrong?
Basically, this is an admission that the average programmer is fairly shitty. Then again, you don't want average programmers working on anything important, so by sticking with c, you're not going to get the "rust, rust, baby" programmers.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
C was one of the most influential languages the world has ever seen, but all things reach a point where time moves and and they are not good ideas for new projects any more. I don't think we should necessarily go replace every line of C code out there - couldn't if we wnanted to - but for new projects we should use better tools now.
Tools do matter. It's just way way way too easy to write buffer overflows in C, even for highly experienced programmers. History shows that clearly. We need better tools that are not so dependent on the human being doing the checking. That isn't to argue you can't write bugs in Rust, just that it helps the programmer avoid some classes of problems. Slashdot readers tend to think "if it isn't 100% perfect and can't guarantee bug-free code then it must be worthless", but that's autism thinking at its finest.
People get attached to "the way things have always been done", but sometimes it really is best to move on. Yes, there is still COBOL code out in the world but that's not a language people use very often now for new projects. It did its job decades ago but we have learned lessons since then and we don't have to repeat the mistakes of the past.
It's time to leave C in the past.
The Rust community really worries me. It's far too tyrannical for my tastes. For example, they apparently aren't capable of acting like civilized adults on their own. They need a Code of Conduct to tell them how to behave, and a Moderation Team to act as what is effectively a judge/jury/executioner role.
What's worse is when they use these tyrannical apparatuses to attack others. For all of their bragging about how they value "tolerance" and "inclusivity", they so often exhibit the opposite behaviors. Just look at any Reddit or Hacker News discussion about Rust. Anyone who doesn't post a glowingly positive comment about Rust will quickly become the victim of downvote attacks. It worries me when people offering valid, correct and relevant criticisms of a technology are attacked, censored and silenced.
I've used a lot of languages over the years, from C to C++ to Java to Perl to PHP to Erlang to Haskell. But none of them have had communities as hypocritical, contradictory and tyrannical as I have found Rust's to be.
To be able to code effectively in C you need to have been doing so for at least 3 years and, preferably, spent 6 months or more writing in assembler. I am not saying that without this people cannot write good C, but I believe that this is what is needed to provide you with the level of insight that is necessary to be a competent C programmer. To be a great one, add a few years experience.
C is not a language for every one, it is not a language for all problems. But for some it is a good language. The trouble is that some people use it when the, perhaps, should be using another language and then when they get problems blame the language and not themselves.
Anyway: how can you call a language complete if it does not have a GOTO statement ? I'm not saying that I use it a lot, but it is useful for handling errors & similar. I will doubtless now be flamed by those who have heard Dijkstra's complaint about GOTO and not understood it. I remember programs where one in every three statements was a GOTO - yuck, that is what he was complaining about; not about the single GOTO in every 1,000 to 3,000 lines that I seem to write. Yes: I could eliminate those GOTOs but either by making the program less clear (by introducing extra state variables, or similar) or by making it less efficient. His complaint was about excessive use of GOTO, many who have not read the paper, or do not have enough real programming experience, forget that important qualification.
Hire competent C developers and you should be good to go. Hire dumb-asses and sure the future doesn't look bright.
A competent C developer will make only a very small number of mistakes per N lines of code, so that's a good thing.
Of course, it only takes a single tiny mistake to produce potentially devastating consequences, so unless every single one of your C developers is not just good, but infallible, then by hiring "only" competent C programmers you are guaranteeing that your software will include a security hole, sooner or later.
The problem with infallible C programmers is that they do not exist. The problem with competent C programmers is that there are only a limited number of them around, and it's not always easy to tell up front the competent C programmers from the seemingly-competent ones. Not to mention that every competent C programmer started out as a less-than-competent C programmer; if companies hired only competent C programmers, there would not be any competent C programmers since nobody would be able to make a living as a C programmer during the first N years of their programming career.
Since the whole point of computers is to automate processes to make them quicker, easier, and less susceptible to human error, why would you not want to automate the creation of secure software, to the extent it is practical to do so?
The linux kernel is in its 3rd decade, as most gnu/bsd tools and all of that is written in plain C. They are good and safe.
Why do you think the Linux kernel is good and safe? It has suffered from many security holes in the past, and will probably suffer from more in the future. There are almost certainly multiple gaping security holes in the Linux kernel right now, just waiting to be discovered and exploited. And this is despite it being written by competent guys.
Imagine how much more robust the Linux kernel would be if the competent guys were also using a language that caught more of their mistakes at compile-time, rather than leaving them to be discovered by testers, users or hackers at some later date. Dunno if Rust is the language to do that, but it's hard to see how automatic coding-error detection wouldn't be a big improvement over the status quo.
I don't care if it's 90,000 hectares. That lake was not my doing.
The particular interesting thing about -avionics- is the cost of development is dwarfed by the cost of verification. I remember a presentation by Boeing Commercial Aircraft on the 777. They said, "We've done DO-178b Level A in a bunch of languages. For most languages, the cost to develop and the cost to verify is pretty much the same. For Ada [Ada83 - this was in the 90s], the cost to develop in Ada was 25% more than other languages. But the cost to -verify- that Ada was about 1/4 the cost of any other language. DO-178b Verification costs up to 10x development," He wouldn't say just how much that cost for 777, but he strongly implied it was multiple billions of dollars.