Of course you can. But it is much harder. I'm just having some fun. Anecdotally, Rust coerces you into writing sound code and really helps break some destructi

Of course you can. But it is much harder. I'm just having some fun. Anecdotally, Rust coerces you into writing sound code and really helps break some destructive habits that C breeds. I rarely need to debug Rust code and when I do the bugs are logic errors not memory errors. It's a noticeable difference. For lightweight contributions to the kernel and "peripheral" contributions (where some big company writes a massive messy driver because the market forces their hand.. not because they enjoy curating and actively helping to maintain linux), the type of discipline Rust enforces is invaluable. Also, what do you mean that Rust won't solve use after free? The whole point of the borrow checker is tracking and enforcing reference lifetimes in order to prevent using a pointer to memory that's been dropped from scope and no longer has an owner (has been freed). Sure it can't prevent all issues magically just yet (there are limitations) but it's a positive force in the right direction. Rust forces developers to do upfront what is usually relegated to careful code review. You're forced to think about the memory implications of your code. If the issue is that we can't thoroughly review the abundance of code submitted to the kernel, then e.g. requiring that, unless justified, new patches shall land in safe rust, seems like it would directly address the core issue that there aren't enough eyes on the code. Obviously it's more nuanced than that, there's existing code you can't just say "all new contributions must be rust".. the example is just illustrative. The existing proposal and work on carefully incorporating rust into the kernel is super awesome. And I'm excited!