It'd be really exciting if they make a safe Rust API for kernel drivers. You can technically write a driver in Rust, but the bulk of your code will be interacting with the unsafe, complex C API, so it's a bit pointless.
A more serious counter argument is that Mozilla did exactly this with Rust in Firefox - and it seems to be a success, there's still lots of Rust in the browser and it seemingly is working.
Point being, using Rust for all of the things will probably be painfully cumbersome today, but writing up a complicated enough component with a well defined boundary with the rest of the kernel will probably prove immensely useful and won't be painfully cumbersome.
There is even a template library for it, Windows Implementation Libray, WIL.
C++ has been usable in the Windows kernel for a long time but you need to make sure that code ends up in the correct PE segment types for pageable and non pageable code and that there are no hidden gotchas for features like exception unwinding and that new can use paged or non paged pool appropriately. Same for Rust: getting to a nostd etc that is compatible with kernel use.
I think there’s a strong case that many drivers could be written with either a user mode driver framework or a small VM. Most of the hardware devices I’ve worked with we just need fast transfers of data to user mode buffers so our application can handle it, and the code is mostly boilerplate framework code plus setting up device registers to set up DMA transfers. I don’t see why that couldn’t be handled with say an EBPF or WASM equivalent byte code.
https://community.osr.com/discussion/291326/the-new-wil-libr...
> wil was primarily developed by the Windows shell team for writing usermode code, but the NDIS and Bluetooth teams have contributed some small kernel-specific features. Here's a few examples of how you can use wil in your kernel driver: