While I like Rust and get paid to work in it, and am happy it's now possible to work in the kernel in it, I am skeptical about the promise of Rust to solve issu

While I like Rust and get paid to work in it, and am happy it's now possible to work in the kernel in it, I am skeptical about the promise of Rust to solve issues like this, honestly; at least the for short term... Because I think once you get down to the kind of code being written here it's going to be chock full of unsafe {} and UnsafeCell and various snakey error-prone tricks to make the borrow checker work in the context of the entirely different world that is the kernel, closer to the metal. And so realistically most of the same issues that impact C code will happen here. I haven't looked at the io_uring security issues in general but I've used io_uring (from Rust) and I can see how it could go wrong. And I can see that if one was writing a facility like this in Rust it could end up subject to many of the same issues, because in the end io_uring is holding references to user instructions and executing them in a pretty privileged context. Many things could go wrong here: how one manages ownership, what the boundaries between this thing and the rest of the kernel look like, etc. There's no magic bullet that Rust provides there, other than perhaps an expectation of a certain kind of borrowing discipline? Hopefully Google shutting this down in their GKE environment doesn't spread beyond into AWS and Azure hosted instances, etc. because I think there's plenty of people who will be impacted quite negatively. io_uring has incredible promise, and the kinds of companies that it will hurt are the fairly innovative ones pushing the envelope for database or server tech generally (including a former employer of mine!).