Rust only helps in a specifc use case of data races, when the memory belongs to the same process and is being access by threads.

Rust type system doesn't help when the data resides in a shared memory segment accessed by multiple processes.

Rust helps against data races in a kernel, as shown by the Rust for Linux project and other kernel projects (Redox, etc).

Of course if you interact with foreign code (including code in other programs, but also code in the same program written in another language), you need unsafe. Or if you write a new synchronization primitive, etc. The unsafe is there to say "I manually checked and this is okay".

What's important is that with Rust, concurrent business logic - in a kernel, things like filesystems and drivers - shouldn't need any unsafe to synchronize correctly. You use unsafe for your lower level infrastructure, but the code that actually does things can be data race free (and thus is easier to modify and assure it's working correctly). And that's incredible.

Filesystems get modified by third parties.

Also the right way to implement filesystems and drivers in modern OSes should be in userspace drivers, which is the route being taken by Apple, Google and Microsoft across their OSes anyway.

> Rust type system doesn't help when the data resides in a shared memory segment accessed by multiple processes.

This isn't quite true. You can provide a safe abstraction that involves cross-process locking APIs. https://github.com/elast0ny/shared_memory/blob/HEAD/examples... is an example using a mutex guard.

Rust's type system helps more in some cases than others, but you can get at least some help from it almost all of the time.

Which are worthless on OSes like UNIX, with advisory locking.