> First, there is no reason why we have to choose between Rust in the Linux kernel and a new Rust kernel. First, we may have to choose between those things bec

> First, there is no reason why we have to choose between Rust in the Linux kernel and a new Rust kernel. First, we may have to choose between those things because Rust in the Linux kernel is not gaining traction and major contributors are dropping out rather than seeing it through. It's valid to speculate about alternatives. Second, software development is not a zero-sum game and such a rewrite can exist in concert with Rust-for-Linux (and even benefit from it). Drew is not handing out orders here anyway. > Second, this would perpetuate toxic LKML behavior. I'd suggest maybe this bad behavior should be dealt with. You've used the passive voice here, and the probable reason for that is that there is nobody who is or will ever be responsible for dealing with LKML's shitty "culture." It's a cesspool at every level and will continue to be so until everyone currently in a leadership position is gone. In addition, the problem here is not technical. Rust is a solution to some technical problems, but technical decisions in a mature group effort are secondary to what Filho referred to as "nontechnical nonsense." That nonsense is the single most important aspect of the project, and too many of the Rust-for-Linux proponents don't seem to understand that. Without developer buy-in, none of your advanced futuristic solutions are even going to make it in the door. The fact that many of the developers whose buy-in you need are assholes is not grounds to reject the work. It simply makes the work less pleasant. Linux moves forward because the people who build it are moving in the same direction. If you want that direction to change, you have to convince a majority of the actors. You're not going to do that by telling them the tools they've used for decades are bad and wrong and the answer is this other shit you happen to be good at. People keep making this assumption that Rust-for-Linux is hindered by technology considerations, but that was never the case. It is and always has been a sales pitch, and the Rust-for-Linux people have completely fumbled the ball at almost every stage. There is a great example in Filho's linked video where he's showing get_or_create_inode and the C devs (poorly and abrasively) try to explain that this design means to implement special cases you have to go fucking around in the type system instead of just branching differently in the call site where the other logic is. Filho gets frustrated because he can't seem to understand that using types this way is not intuitive for many people, and the C people get frustrated because Filho's answers don't account for their objections at all. There's another great example in this very thread where you declare that "the Rust devs showed an better/easier way." They, arguably, did not, if you're not a Rust dev. To someone who isn't accustomed to idiomatic Rust, it seems completely insane to have to go digging around in the type system in order to enable magic elsewhere in the call stack, when you can just tell the computer what to do. Nobody at any point is trying to demonstrate why the Rust approach is superior -- a position I happen to agree with, for the record -- and instead just bemoan these stupid C toddlers who don't take the same things for granted that Rust adults do. It's pointlessly demeaning, combative, and in this case self-defeating, and it's the primary reason I think projects which use Rust ab initio succeed more than these piecemeal approaches.