Both of statements can be true, though. Developers skilled enough / brave enough to write kernel drivers can be very careful about not leaking memory or mismana

Both of statements can be true, though. Developers skilled enough / brave enough to write kernel drivers can be very careful about not leaking memory or mismanaging the hardware in question, and Rust can make that job much easier by being pedantic about memory mistakes or type misuses (with custom types that are validated at compile time but no runtime overhead). I've worked on C and Rust codebases, though nothing near as complex as the Linux kernel, and I'm excited for this change as it will reduce the burden on the kernel developers to reach the same quality output, so we either get drivers faster, or drivers for hardware we wouldn't have otherwise received, or both. As far as the fear of Rust kernel drivers that don't compile with GCC's Rust frontend, I trust Linus to keep the bar high on letting this feature in, and that kernel drivers accepted into the tree compile with just GCC as they always have. Third-party drivers may not, but that's also true today if someone wrote a driver that only compiled with LLVM. This doesn't really happen in practice as it goes against the path-of-least-resistance for the developer: they'd have to switch their toolset out when working on that driver vs everything else, and the auto-building by DKMS would probably fail on them if they used it during development -- all of the conventions used by the rest of the kernel infrastructure will keep them in line.