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...
To demonstrate the claim that C and Rust have different idiomatic data structures you need to rewrite software from C to Rust and to Rust from C and see what is hard and what is less hard.
The C stdlib does not come with an AVL tree. Why would one not implement a b-tree in C for this comparison? It’s not as if K&R has “Use binary, not b-trees!” on the front cover.
For example, the benchmark shootout recommends his khash for a hash table.
I don't think anybody will find any consistent performance enhancement in Rust that can not be replicated in C. The problem is how to run it out on real code.
I once did a similar benchmark to the one in the article and found that Rust outperformed C++ because the C++ code was using the builtin std::map. But for reeeeeeally big datasets PostgreSQL beats them both so who cares. :p