Zig isn't finished yet. Rust has stable language features.
You also don't need async in many if not most cases, especially if you're writing kernel code. I wouldn't want to use a kernel module that pulls in all of tokio/reqwest/hyper just like I don't want a kernel module that links against openssl.
Async makes a lot of sense for userland code, but not so much for kernel code. I haven't seen async get used in any demo for kernel Rust modules and I doubt it'll happen anyway.
Looking at a comparison between common kernel structures and theoretical Rust implementations of those (like on https://security.googleblog.com/2021/04/rust-in-linux-kernel...) I think the kernel can get improved security and reliability from Rust without any "fancy" Rust. Just the basic type system improvements, nullability improvements and explicit checks will be enough for some real benefits.
> You also don't need async in many if not most cases, especially if you're writing kernel code.
Have you seen how much communication with the hardware in drivers is actually very asynchronous? It’s all hand rolled C, of course, but there’s a lot of it.
But look at the bright side: people likely won’t be enjoying hand-rolling asynchronous Rust since language-level primitives exist, so maybe there will be enough pressure and enough of use case diversity to make a more solid implementation that doesn’t suck, or sucks way less than the current one.
Currently the rust ecosystem is rapidly moving towards treating tokio as the default-and-only async runtime. If the linux kernel community establishes an async runtime tuned for embedded/kernel use cases that could bring some much needed diversity and speed up the process of making async ergonomic and less bolted-on.
What do you consider "hand rolled"? The kernel has extensive support for these use cases since, as you said, hardware is usually async. Async with hardware is rarely tangled, from my limited experience. It's usually event driven.
I mean that it’s not hidden behind some all-encompassing event loop, nor is there an all-encompassing framework with an event loop hidden from you. It’s more like an exploded view of a mechanism in comparison.
You also don't need async in many if not most cases, especially if you're writing kernel code. I wouldn't want to use a kernel module that pulls in all of tokio/reqwest/hyper just like I don't want a kernel module that links against openssl.
Async makes a lot of sense for userland code, but not so much for kernel code. I haven't seen async get used in any demo for kernel Rust modules and I doubt it'll happen anyway.
Looking at a comparison between common kernel structures and theoretical Rust implementations of those (like on https://security.googleblog.com/2021/04/rust-in-linux-kernel...) I think the kernel can get improved security and reliability from Rust without any "fancy" Rust. Just the basic type system improvements, nullability improvements and explicit checks will be enough for some real benefits.