The parent actually said "Rust or pretty much anything else", which means any memory safe language. It just happens that Rust came to his/her mind as the first choice probably because it's been talked a lot about lately on HN and memory safety is its explicit focus.

I see no "programming languages a religion zealotry" in parents post, but I see a lot of bitterness in yours. Perhaps it's time to reflect.

There are tons of vulnerabilities discovered every month. Most of the them are in Java, PHP, javascript, etc. software because that's what the majortiy fo new code is written in. And those languages have features that can lead to security holes, which C doesn't have. For example, PHP supports eval(), JS has cross-site scripting attacks, Java has classloaders, etc. etc. But somehow only the vulnerabilities in C language software get programming language zealots exited. So maybe you should reflect.

Oracle JVM/OpenJDK and .net CLR are deployed in production at basically every profitable company on Earth.

PHP... Is deployed because it's perceived to be easier and friendlier than other religions, and so wins with that popularity war (as MySQL did). Facebook HHVM is another approach. Folks know the likely warts and mitigate to shrink the attack surface by defending deeply from front layers down to backend services.

Postgres was harder to use in the 2000's despite having a clean codebase but got mucb easier to use, in large part due to MySQL, while leading on features inspired by Oracle DBMS and more recently NoSQLs with hstore.

Attacking popularity for what gets the job done is moot because defense is never ending vigilance for anything real.

Perhaps the focus should be on starting to formally-verifying core libs like zlib, OpenSSL, OpenSSH (portable), glibc, etc. for correctness and resilience against side-effects and ABI promises.

JavaScript doesn't have XSS. The DOM allows for XSS vulnerabilities, but that's an API, not the language.

Well you kindof sound like a performance zealot. Burn some cycles, stop running unmanaged code, just take the hit. It should be justifiable if a Rust implementation of a library is 5-10% slower than its C equivalent. How can choosing to build and deploy unsafe code in today's legal/political/financial environment be defensible? Is it going to take public shaming and frogmarching developers to jail for our industry to make a change?

We need to discredit performance zealots and gently herd them to a profitable careers in videogame development where they can't do much harm.

And, there's plenty to dog on Java about, but that language and VM very intentionally makes it an ordeal to load a 3rd party binary blob. Modern development systems/VM's seem to have waved off concerns about unmanaged code and security; Node.JS compiles and loads binary blobs from dependencies all willy-nilly. Java took and takes security seriously.

Depending on what you're doing, it might even be faster, not 5-10% slower. We're currently sometimes faster, sometimes slower, but we should never be slower by a huuuuuge magnitude, though of course, bugs do exist.

I've been excitedly watching this over time; I think in a few years Rust could just be straight-up faster than C the majority of the time, depending.

I think you're right with all the new opportunities for optimization in Rust.

I wanted to encourage developers to be open to compiled Rust being nowhere-near an order of magnitude slower than equivalent compiled C and still have it be an acceptable architecture choice for systems-programming.

Absolutely. I think trading a bit of speed for a bit of safety is the right choice 99.99% of the time. I've just been excited to watch the benchmarks improve :)

It doesn't have to be a big rewrite of "everything" to Rust. It would at the very least be a slow successive rewrite whenever a major change is needed.

For this particular piece of code one would hope that the fix we'll see now would also include around 100 new lines of comments, splitting of hundred-line functions into a dozen smaller ones etc. I suspect that just by doing that someone would notice another flaw of this magnitude. Also, the updated code would be easier to maintain or rewrite in the future. The whole idea that all changes are kept as small as possible because of concerns that refactoring might break something says something about how brittle it is and how much of the testing is just battle hardening and not proper tests.

> It doesn't have to be a big rewrite of "everything" to Rust. It would at the very least be a slow successive rewrite whenever a major change is needed.

That's why the suggestion to implement BSD sockets first is an interesting one. It's a non-trivial interface (which is important to be a useful proof of concept), but it's widely used, relatively well-defined, and could potentially be plugged into applications without replacing other pieces (though that may turn out to be tricky). If it works, you could start implementing more native interfaces that way. If it doesn't, maybe we'll understand better why C remains so dominant for system libraries. (Personally, I don't think it's just inertia or the cost of rewriting all that software, but that's why I'd like to see a project like the one suggested.)

I think you're misreading what he says. "...replacing it with Rust /or pretty much anything else/" (emphasis own). The point is we should be replacing C with /pretty much anything else/. Rust looks like the most obvious (but not necessary correct) candidate.

Also performance is not such a big deal as dictate security considerations. One's fancy medical web app is worthless if it leaves the potential for theft of medical data.

But why is it religion to look at all the problems caused by C code and say, let's try something that doesn't have these problems? Why isn't it religion to look at that history and say no, it's okay, let's keep using C?

The overall goal of reducing deployed LOC, complexity and low-level boilerplate is laudable and doable so by using a C isomorphic linking language (can call into and can call from) to gradually, experimenting by converting one module at a time and increasing tempo of semver API refactorings for also reducing code and features to the essentials. "The journey of a thousand miles begins..."

Also, we need more unit testing, fuzzing and formally proven correct libraries (a-la seL4). Most C development is really bad about unit testing and fuzzing because it's incredibly laborious and verbose, even when it's known to be a good idea.