The answer depends on a still unresolved issue of whether RFL can build usable safe and zero-overhead abstractions around kernel APIs. This work isn't complete,

The answer depends on a still unresolved issue of whether RFL can build usable safe and zero-overhead abstractions around kernel APIs. This work isn't complete, and it's hard to say whether the current issues are from immature integration, or a sign there are fundamental limitations. Rust was able to give safety guarantees where other languages couldn't by forbidding certain code patterns that complicate or break static analysis (ambiguous ownership, unrestricted mutations). Rust also has its own arbitrary design choices such as reserving a right to memcpy structs to a different address. For Rust code written from scratch these limitations are not a big deal. Rust programs pick architectures and design patterns that work with and not against the language. But Linux never had to worry about having statically known ownership of pointers. It could do whatever it wanted with uninitialized memory. It could play with pointers however it wanted. So RFL needs to bend backwards to support design patterns that are not idiomatic Rust. It remains to be seen where the compromise will end up (less safe Rust APIs? or more complex? Not zero-overhead? Maybe the Linux will change its APIs to fit Rust, or maybe Rust will change to help RFL).