Direct link to Linus' email: https://lkml.org/lkml/2025/2/20/2066
It's an interesting discussion. There's always a divide when you slowly migrate from one thing to another.
What makes this interesting is that the difference between C code an Rust code is not something you can just ignore. You will lose developers who simply don't want or can spend the time to get into the intricacies of a new language. And you will temporarily have a codebase where 2 worlds collide.
I wonder how in retrospect they will think about the decisions they made today.
There was always going to be some kicking and screaming on this tbh. This strikes me as a reasonable middle ground
As a C maintainer, you should care how the other side of the interface is implemented even if you're not actively involved in writing that code. I don't think it is reasonable, for software quality reasons, to have a policy where a maintainer can simply pretend the other side doesn't exist.
previous discussion https://news.ycombinator.com/item?id=43123104
I get the feeling that, no matter how slow Linus goes, this is going to lead to a split. If Linus eventually pushes through Rust, the old guard will fork to a C-only version, and that won't be good.
What does this mean for kernel compilation times and toolchain requirements
>We've turned our development model into a well-oiled engineering marvel
Especially those mailing list, engineering marvel, indeed!
Linus said that non-rustacean C programmers cannot veto rust code, but he did not clearly state how it works going the opposite way. It was rustacean-proposed changes on the C side that led to this drama. I don't see much progress here.
I can see only one viable path for Rust folks: Fork the kernel and make whatever mods are needed. It's not Linux anymore, but that's how Linux started from Unix all those years ago.
You can see that Linus actually makes an effort to be at least somewhat nice nowdays, while still sticking to pragmatic technical decisions.