Rust is good at preventing memory leaks. It doesn't matter (as much) for a command line utility that runs for one second then exits. Of course, there are now utilities written in Rust. https://github.com/samuela/rustybox
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.
>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.
To improve security, Rust should probably aim to replace libjpeg and other stuff which deals with malicious data a lot.
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.
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.
The point is defense in depth.