Rust doesn't promise to be "all safe." Rust promises to clearly delineate the points in code where the compiler cannot guarantee memory safety on its own.
Which makes it clear for Redox and all other Rust OS projects, you're just shrinking down the magic layer, not erasing it. Most code paths will still hit inline assembler.
If one goes to Redox page, it says pretty clear - bringing Rust innovations to operating system level. It's a quite cool project, something that MS's Singularity could've been if it wasn't a purely research thing. It utilizes a modern language ecosystem to implement an OS.
Nothing there implies any sort of 'rewrite push' or whatever Rust zealots are talking about these days, as we can see, the people who both know the problem domain of OS and enough about Rust to tackle it with, decided to build something from ground up.
Can such OS be competitive? Yes, if it can bring in the hardware support. As a microkernel Redox can leave that to standard 3rd party packages, also preferably written in Rust.
And that means, somebody is going to have to port a billion of lines of code of device and facility drivers from their reference implementation in kernel C, to Rust.
One can see a circle here, unless OS project in Rust becomes competitive enough, reference developers won't use it. C is "unsafe", yet most of the cryptography algorithm reference implementations are in C. This is due to decades of gathered best practices and piled up codebase.
If one wants to "replace C" good luck with breaking this circle. There is no such intent behind Redox, they build a great thing there, Unix microkernels are the optimum, the middle ground between technology and philosophy.
Speaking of which, the Rust zealots who think they'd be able to write systems code if somehow "OS digested Rust", well their wish could happen easily with a C written microkernel, because it could host fully safe userspace drivers.
go.dev
