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.
Why now? Why rust? What about Ada? They're not so different that somehow the argument becomes that much better than it was for Ada. I just don't get all this rust hype. But, then again, I'm a C programmer, and I am 100% certainly I won't see C replaced in the systems I work on (cars), so it's a moot point. I would, however, support a move to Ada. My industry would never consider Rust. Pushing it over Ada is actually counterproduction, because it primes the C-suite to see languages pushed as a replacement for C as immature. Rust is still immature, way too immature for a conservative industry. Ada, though... maybe not.
Hire competent C developers and you should be good to go. Hire dumb-asses and sure the future doesn't look bright.
The usual PR stunt of "use my new language that is so good and so simple even a stupid high school teen with an IQ somewhere between stone and plankton in the phylogenetic tree could use it without wrecking anything" is not going to convince anybody here. It's boring at best, and no-one cares about your "advice".
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. Oh, maybe it's because they are written by competent guys.
Video of some good progressive thrash music
If something needs to be done in C because it talks to hardware (and everything operation that computes eventually talks to hardware), then having another layer in front of it that still needs to talk to C code doesn't necessarily get rid your chance to make mistakes; it might in fact leave you even more rope to hang yourself with. And it won't look like the same kinds of errors you're making now, which is why you don't foresee it.
One is data structures: in C there are no data structures. Any memory can be treated any way you like. So you can pack different bits and bytes together on one end and have them make sense on the other. At the cost of a potential security hole. But sometimes that's how you need to talk to hardware and for speed's sake, the thing that talks to the thing that talks to the hardware speaks the same language. Now if you impose a type-safe bounds-checked language anywhere in there, then one of three things will happen:
1. You can't do in the type safe language what you used to be able to do in C because you can't specify the necessary data structures anymore.
2. You can do it, but it costs you a ton of extra execution time, because even though you can *specify* an analogous variable-length data structure in your type safe language, the newer and better language makes no guarantees about how that data actually resides in memory, so when it gets to the C layer, there's a bunch of gathering and reconstructing and recreating that packed data from various places, all with bounds check overhead. This is what happens in Java.
3. You can do it, but you have to write a language extension to support what you're doing. And guess what language you have to write it in? C!
Yes. Formal verification of most production programs will not happen in my lifetime or yours, or possibly ever, because it's expensive and nobody's paying for it.
The simple fact is that there's a hue and cry about security but nobody really cares about it, because nobody's willing and able to pay what it would take to fix it.
Rust is very tied to Mozilla. And Mozilla's only remaining "successful" product is Firefox. But Firefox's market share is dropping. It was only a few percent, last I saw, while Chrome is over 50%. Mozilla reportedly gets a lot of funding from Yahoo, due to a Firefox search deal. So here we have an organization with one major product, but this project is being rejected by consumers, and what might be this organization's most significant source of revenue comes from this failing product and is paid for by another company that isn't doing so well. I fear for Mozilla's future if, say, the Yahoo deal wasn't renewed and they couldn't find a replacement.
If Mozilla goes the way of the dodo bird, then I can't see the Rust project really going anywhere. I don't think it has a robust independent community like Python or C++ has, for example.
I think it is too risky to adopt Rust, especially for important long term projects. The tech industry moves fast. Rust could plausibly be gone in 3 years, while languages like C, C++, Python and PHP are far more likely to be going strong.
i've recently converted from C++ to Swift — better modern native unicode string handling, and scales really well from beginner semantics all the way to system level stuff. its a great language to work in — and written by chris lattner (who wrote the clang and LLVM compiler/architecture) — so its well fitted for performance optimizations/very fast.
swift is the first language that i'd say i feel comfortable replacing C++ with.
2cents from toronto
john p
A much better argument against formal regulation of the software development profession is that we don't know the best way to do it yet.
We have centuries of experience building bridges, and have a pretty good idea of how to build bridges that don't fall down by accident, even under unlikely but plausible conditions like freak weather events or excessive loading because the public ignore some limit or other.
We have decades of experience building software at all, and little consensus on the best way to do it. Indeed, we don't even have a clear definition for what "best" means in this context, and it's possible that depending on the purpose of and risks associated with software, a reasonable set of good practices might look entirely different in one case from another.
Worse, the people who are most qualified to judge when we do reach that level of maturity within the industry, and to formally recognise good practices, are probably among the least likely to actually do that. They're probably too busy building good software where quality matters.
Instead, there must be an all too realistic possibility that any formal regulatory system would be dominated by the famous consultblogauthspeakers who spend a career burnishing their profile within the industry, but who in many cases have remarkably little experience actually building working software of their own, never mind working software to a very high quality standard. The very last thing we need is these fools being given any real authority over developers who are trying to do better, or $DEITY forbid, being required to give their blessing to those developers before anyone can ship anything.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I had the exact opposite experience! I have never had such a positive experience with a programming community of any sort as I have with the Rust community. I have never seen an open source project put so much thought and effort into the community side of things. Because of my interaction with the community, I ended up contributing a couple patches and giving two talks about Rust at a conference this last week.
Pascal is the only language that's created a verified A-1 secure computer system, so let's use that.
How about this: rewrite systemd in Rust first and I might consider it.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Most people have literally no idea what it would actually cost to prevent security issues and other bugs using formal methods. The average developer probably hasn't even heard of them, and I'd guess less than 5% of professionals have any substantial knowledge of the relevant tools and techniques or have ever actually used anything much beyond a type system for this purpose.
It may well be that organisations assume that the cost of prevention will be higher, but their ignorance is not an argument. (Neither is calling me names, by the way.)
Finally, your hypothetical $100K low risk vulnerability is irrelevant, given that within the past few weeks alone we have seen major security outbreaks with consequences like bringing down large parts of the NHS infrastructure in the UK, which probably cost lives and certainly caused a great deal of unnecessary suffering. Even the lower bound on the cost of security screw-ups in modern software includes people dying unnecessarily.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Why replace it at all? Why not just introduce new features into the c compilers, language, and libraries that just identify and correct bad patterns and practices?
Because at some point, you can't keep building skyscrapers on shaky foundations. If the underlying programming model in your language doesn't provide some useful guarantee in relation to the correctness of your code, there is only so much you can do. Even modern C and C++ are very far into the not-providing-guarantees area compared to many other languages that have been designed with correctness in mind and the benefit of decades more collective experience in the industry.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
It's just way way way too easy to write buffer overflows in C
Technically: it's too easy to write buffer overflows in most implementations of C. The C specification makes accessing beyond the end of a buffer undefined behaviour. That means that an implementation is allowed to do whatever it wants (and doesn't have to do the same thing consistently). Most implementations implement this as 'trample an arbitrary memory location', but it's completely valid to transform it into a recoverable trap. My research group has proposed a small set of CPU extensions that we're talking to vendors about adopting that allows an implementation of C (which I've created and which we're able to build complex C programs with) that provides these guarantees. Any out-of-bounds array access for us is a CPU trap, which the OS turns into a signal. You can then either kill the process, unwind the stack and kill the thread, or recover in some other way.
I am TheRaven on Soylent News