The amount of unsafe is pretty small and limited to where the interfacing with io or relevant stuff is actually happening. For example (random selection) https://lkml.org/lkml/2023/3/7/764 has a few unsafes, but either: a) trivial structure access, or b) documented regarding why it's valid. The rest of the code still benefits.

But that's not the only reason Rust is useful - see the end of the write-up from the module author https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ ("Rust is magical!" section)

I’ve done a decent amount of low level code - (never written a driver but I’m still young). The vast majority of it can be safe, and call into unsafe wrapped when needed. My experience is that a very very small amount of stuff actually needs unsafe and the only reason the unsafe C code is used is because it’s possible not because it’s necessary.

It is interesting how many very experienced programmers have not yet learned your lesson, so you may be young but you are doing very well indeed. Kudos.

Hah I’m not that young - it’s a figure of speech!

Either way, the point you are making is an excellent one. Discipline makes for better programming, and to not use the features available to you is very often the right choice.

Unsafe in Rust doesn't mean anything goes. Specifically it means that you are going to 1) dereference a raw pointer; or 2) call an unsafe function/method; or 3) access/modify a mutable static variable; or 4) implement an unsafe trait; or 5) access fields of a union.

You still get the safety guarantees of Rust in unsafe code like bounds checking and lifetimes.

The point is that lots of the code won't be `unsafe`, and therefore you benefit from memory safety in those parts.

Why does that matter? Rust with some "unsafe" is still much nicer to use than C.

In fact one of the main points of Rust is the ability to build safe abstractions on top of unsafe code, rather than every line in the entire program always being unsafe and possibly invoking UB.