I think Theo's reply was a bit excessive in some regards but I can also understand him being frustrated when you've been working on a very complex project for decades and somebody comes around and say "uh, why don't you rewrite it in <hype new language>?".

It's seldom a very interesting or constructive discussion. If you think Rust has something to bring to some project then you should at least take the time to write a decent proof of concept or something similar, not ask the current maintainers to rewrite their codebase in Rust/Go/Haskell/Prolog because of some purely theoretical benefits. You don't go to construction workers in the street and tell them that they should consider using different types of hammers.

I don’t think Linux or bsd will ever be rewritten in rust nor should they. I do think eventually there will be an os written in rust that surpasses them in popularity, but probably on the time frame of decades.

There are not many CVEs for coreutils anyways: https://www.cvedetails.com/product/5075/GNU-Coreutils.html?v...

To improve security, Rust should probably aim to replace libjpeg and other stuff which deals with malicious data a lot.

coreutils are often run on untrusted data.

I think he was very polite.

I didn't mean to imply that he was rude, merely that his dismissal went a bit too far. He threw the baby out with the bathwater, so to speak. In particular this bit:

>As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts.

This doesn't really match what I saw of the Rust ecosystem and, even if it did, being able to write proprietary web-facing apps doesn't preclude one from writing "Unix parts". It's as if I said that C++ couldn't be used to write Unix utilities because it's used to write proprietary videogames. It's not a very good argument IMO.

The crux of his argument isn’t really that these tools can’t be written. The self-bootstrapping requirement of OpenBSD means that incorporating one Rust-based core utility would require Rust and LLVM to be built when building OpenBSD, which is an incredibly large cost. It’s simply too early to seriously entertain such a notion.

Once there are a large number of core utilities implemented in Rust that show some significant practical benefit over the C versions, the situation may be different.

(Rust does not guarantee the prevention of memory leaks, to be clear)

can you elaborate please?

... I am not really sure how to elaborate, to be honest. Rust prevents memory unsafety, but memory leaks are not memory un-safe. There are many kinds of bugs that Rust does not prevent. Leaks are one of them.

How can leaked memory, pragmatically, be considered safe? The language spec definition seems useless.

The only issue memory leaks can cause is being a DDoS vector. Memory unsafety can cause a host of other issues, and much more serious ones.

It is also very difficult to come up with a definition of "memory leak" that doesn't include programmer intention, and so it's not clear that you can come up with static analysis to preclude it.

Agreed there is not much you can do about a programmer using memory in an unsafe way...so what is the point?

You can, in general. Just not for memory leaks.

The point is defense in depth.

While it's clear that writing tools from the start in Rust can prevent memory leaks, this project isn't a great example. It won't be safe until the community refactors it out and fixes all the c2rust unsafe calls.