If c were built with good generics and memory management (not that garbage preprocessor stuff), I expect similarly expressive and good data-structures would be built.
C++ is an affirmation of this because it happens to have good libraries of data-structures which are not really very different from rust's.
I don't think this is as much "rust's design forces the coder to do this" and more "c makes it hard to do as nice of a design"
People can and do get C right, in safety critical systems, at larges scale, all over the world.
By the way, Rust devs are working on a mathematical formalization of those rules. Here's a blog post about a part of this effort: https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html. (There are similar formalization efforts for subsets of C, that led to software like the CompCert verified compiler)
And it would be wrong in differing. Memory and synchronization bugs the kind of Rust prevents are found in the kernel all the time.
The point of the Unsafe Rust is the containment of relative "unsafeness" (that is, however, not equivalent to C/C++'s UB [1]) within a certain boundary. Having less things to audit surely helps.
[1] https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
That said, of course Rust is not a panacea for memory and synchronization bugs. Rust helps a lot but does not fully solve logical memory leaks and deadlocks for example.
As for a kernel just ending up as a bunch of unsafe, doesn't seem grounded in reality.
https://os.phil-opp.com/minimal-rust-kernel/
> Note that there's an unsafe block around all memory writes. The reason is that the Rust compiler can't prove that the raw pointers we create are valid.
[..]
> I want to emphasize that this is not the way we want to do things in Rust! I
[..]
> So we want to minimize the use of unsafe as much as possible. Rust gives us the ability to do this by creating safe abstractions. For example, we could create a VGA buffer type that encapsulates all unsafety and ensures that it is impossible to do anything wrong from the outside. This way, we would only need minimal amounts of unsafe and can be sure that we don't violate memory safety. We will create such a safe VGA buffer abstraction in the next post.
As is always the response to the "A kernel in rust would be just as unsafe as a kernel in C", the goal is to build safe abstractions.
So you have unsafe, plus some constraints that you enforce at a module level, which wraps the unsafety.
This is not perfect - you'll still write vulnerable unsafe code, I'm sure, sometimes. But the rest of your code can be built on top of it, and now your unsafe code can be the main target of your testing and verification.
We have no real rust kernel the size of Linux to compare to but I think there's plenty of reason to believe that it would have considerably fewer vulnerabilities and would make auditing far simpler.
Kernel devs are of a different opinion than yours.
Hence the Linux Kernel Self Protection Project initiative.
EDIT: corrected as suggested.
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...