The problem perhaps is that it's mostly a RIIR project. Then again, Rust has given birth to a lot of those that ended up veing pretty great. Like ripgrep.

It's clear that C is a dated language that leads to numerous security problems. It is inevitable that we will switch to OS's written in Rust or similar safe languages, or will see most of Linux rewritten.

It was already dated when compared against something like Modula-2 (1978), pity that OS vendors decided to go with UNIX clones.

I wouldn't call it a RiiR. It takes inspiration from other projects (namely Minix, Plan9, and ZFS for the filesystem) but is otherwise it's own thing and makes some interesting design decisions (e.g. being URL-centered).

The problem with some C belivers is that they lack the imagination to accept how systems programming used to be like before Bell Labs released UNIX V6 source code into the wild, or the paths trailed by other companies before UNIX clones won the server room.

So just like with St. Thomas, apparently we need all those Rewrite in Safe Systems Language XVYZ, to bring the non-belivers into the righteous path.

Which is anyway only half of the battle, as Joe Duffy points out in one of his talks, several developers on the WinDev team dimissed Midori efforts, even with the system running in front of them, providing them wrong in all their remarks about the system.

I enjoy how defensive Rust fans are over their language, it's fun to poke at in my spare time. First of all, Rust is a great language with great ideas in my opinion, but not really fit for systems programming unless you mean on top of an OS like cd grep etc. I think most Rust fans have never written an embedded project or dabbled in lower level code so they assume that it's just perfect for low level.

First you have to work around things like direct memory access, writing a "safe" wrapper around direct memory access doesn't really take it from unsafe to safe and you have to fight the language to do the things you have to do when doing kernel work. Then you have to deal with badly optimized output of the compiler which is fine in an user space program but a no-go in a kernel or even worse on embedded. I know some might say "well you aren't supposed to do that, you need X safety measure" but the hardware doesn't work like that, if you try to apply those concepts to out-of-order execution for example you will incur a heavy performance cost.

tl;dr Rust fanboys should read some kernel device driver code and lower level code before giving their input

Somehow Google has managed to ship drivers written in Rust since Android 12.

>but not really fit for systems programming

Ironically you say this on a submitted project that uses Rust for systems programming.