unless you have to do anything that relies on a C API (such as provided by an OS) with no concept of ownership, then it's a massive task to get that working well with idiomatic rust. You need big glue layers to really make it work.
Rust is a general purpose language that can do systems programming. Zig is a systems programming language.
What does it even mean to be able to "do systems programming" but not actually be a "systems programming language"? I would directly disagree with you, but what you're arguing is so vague that I don't even know what you're trying to claim. The only way I can make sense of this is if you literally define a "systems programming language" as C and only other things that are tightly tied to it, which I guess is fine if you like tautologies but kind of makes even having a concept of " systems programming language" pretty useless.
Kernels are big pieces of software. Rust is used for device drivers mainly, right? So in that case you write an idiomatic rust lib and wrap it in a C interface and load it in.
Actually interfacing with idiomatic C APIs provided by an OS is something else entirely. You can see this is when you compare the Rust ecosystem to Zig; ie Zig has a fantastic io-uring library in the std lib, where as rust has a few scattered crates none of which come close the Zig's ease of use and integration.
One thing I'd like to see is an OS built with rust that could provide its own rusty interface to kernel stuff.
Zig's is in the standard library. From the commits it was started by Joran from Tigerbeetle, and now maintained by mlugg who is a very talented zig programmer.
The popular Rust one is tokio's io-uring crate which
1) relies on libc; the zig one just uses their own stdlib which wraps syscalls
2) Requires all sorts of glue between safe and unsafe rust.
Rust is a general purpose language that can do systems programming. Zig is a systems programming language.
(Safety Coomers please don't downvote)