I am still waiting for Rust people to do something new and innovative. I acknowledge that Rust itself is innovative, don't get me wrong, But where are the true proof-of-concept projects such as the Linux kernel, qemu, git, postgresql, vim, etc. of the Rust world? Rewriting code is a waste of time of time, fragments the eco system, and introduces new bugs. And with a new focus on memory safety and analysis tools and sanitizers evolving, a lot of C code will be made memory safe in the future without needing a rewrite in Rust.
back
5 comments
There's tons of stuff of the kind you're describing in Rust, more than I care to list but I'll offer you some [1-3] that I think would interest you (based on this comment alone). If your perception of what people are doing in Rust is driven by what people post to HN, it may not reflect everything that is going on in that ecosystem.
Fair enough, I may not have the full picture. But "writing an OS in Rust" sounds also seems the "innovative" part is that something is written in Rust. I do not need a new OS in written in a different language. I could use a good open-source CAD tool, or a good open-source FPGA tool chain (maybe those exist, I need to do some research). A language and projects written in it do not impress me if its own novelty is the selling point, but if the language can be used to solve problem I have. But yes, maybe those projects do exist somewhere...
You might be interested in https://mattferraro.dev/posts/cadmium
People are building cool stuff, and happen to do it in Rust.
Many Rust projects have done cool new stuff. Alacritty is possibly the greatest terminal emulator on the market today. I'm not into cryptocurrencies, but Parity and ZCash are doing cool stuff in that space thanks to Rust.
I'm also the author of Pijul, a much simpler and more scalable (yes, both! why choose?) version control system, and of Sanakirja, an on-disk transactional allocator to write persistent datastructures (like B trees, ropes, radix trees, HNSW…).
1) (new and innovative) and (safer, written in rust) are orthogonal attributes.
(2) Rewriting isn't necessarily a waste of time. There are rewrites of some wretchedly vulnerability-prone (and poorly extensible) core infra like ntpd, sudo, etc., that are sorely needed. Plus, rewriting them in a safer language will make it easier for future innovations, because it won't be as terrifying to try to have on them without introducing yet more vulnerabilities.
(3) Same applies to using rust for future components within the kernel and major browsers.
(4) Sanitizers are great, but they're not as strong as what you get from a memory-safe language. Most importantly, sanitizers only check where your tests cover.
(5) ripgrep. It's not a rewrite of grep, it's a rethink, and it's amazing.
They do, you may just not look very much into the ecosystem.
OSes - redox and many other smaller projects
git - pijul is novel, gitoxide is a pure-Rust git reimplementation
vim - Helix, based on vim and kakoune
>a lot of C code will be made memory safe in the future without needing a rewrite in Rust.
Sanitizers don't do what Rust does, and static analyzers cannot make C memory safe. You would have an easier time of bolting a borrow checker onto a subset of C++ than what you're thinking of, IMO.
Aren't most of the standalone wasm runtimes written in rust?
No idea, but according to this site: https://github.com/appcypher/awesome-wasm-runtimes there a wasm runtimes written in all kinds of languages. This does not appear to be a very challenging thing to do, but I haven't look at this closely.
Writing bytecode runtimes is a common thing since 1958 (see UNCOL), only a novelty for those selling WASM as some great invention never done before.
Only this year I started seeing WebAssembly conference talks actually acknowledging the history of bytecode based distribution.