4 ms·
As someone who has done kernel development work (though not Linux), not every part of a kernel is as filled with dragons as you make it out to be. Why would my
by vore 4y ago
As someone who has done kernel development work (though not Linux), not every part of a kernel is as filled with dragons as you make it out to be. Why would my e.g. filesystem driver need to punch a lot of deep unsafe holes down to the internals of memory management? Why can't I make use of a safe abstraction implemented using unsafe code to free myself from caring about those details?
With C, you can only do these kinds of safety guarantees with a lot of discipline. With Rust, you can offload much of your discipline to the compiler.
- afr0ck 4y agoSometimes, you can't make hard walls between subsystems. Some filesystems need very close interaction with memory management to have very good performance. Some objects are accessed and manipulated in a racy way from logically independent places for scalability reasons. I am not against Rust, modularity, etc. But building very high performance systems is just something different.
- bombela 4y agoYou would encode that into types and expose a safe API. The usafe would still be local in scope. For example you might build an abstraction named ReadWriteMutex that guarantees safe access at runtime. I don't see a scenario where this would impede performances. The invariants to validate are the same. But rust would guarantee that it is memory safe.
- vore 4y agoBut do you need this in the 99% of cases? Probably not. You can write productive, performant, and safe code in safe Rust fine. If you do need to do something this exotic, the fundamentals don't change: you still need to take care of memory lifetimes, you still need to ensure thread safety, etc. I really don't think it's as all-or-nothing as you believe it to be.