Replacing C with Rust within the kernel is not going to be peaceful. It's been made clear by now that most Linux developers, including those most prominent, prefer C and do not wish to invest any time or effort accommodating Rust developers.
>but I will always wish people can just stop fighting, and work together.
Two separate ideas are conflated here.
It would make me happy if they stopped fighting, and instead worked separately on their C and Rust kernels respectively.
It is the premise. Without his acceptance of Rust, we wouldn't be at this point.
But he can't realistically do the relevant rust-accommodation work all by himself.
Not does he seem supportive of Rust enough as to replace the top maintainers he trusts and has worked with for a very long time with those that will extend the red carpet for Rust developers.
Perhaps Linus was trying to be kind. But sometimes, just saying "No." is most kind.
He didn't have the luxury of hindsight. He tried to be accommodating. Now, we are in a situation that is not pleasant for anybody involved.
The problem is that neither Linus nor the other prominent maintainers will live forever. C was the right choice in 1991 but today the landscape is different enough that its shortcomings, for the younger generations, are painful to ignore.
So saying yes to Rust, or to some other language that is not filled with foot guns and could also work in the kernel space, is not only a matter of kindness but a matter of long-term strategy for the kernel.
>The problem is that neither Linus nor the other prominent maintainers will live forever.
I agree. But likewise, Linux's design is far from the state of the art. Maybe there's value in letting it be what it always has been. It is not realistic to try to migrate millions of LoCs written with poor structure, to properly structured Rust, with barely any support from the pre-existing developers.
At some time, it makes sense to move on to something better. This hypothetical system be written in a different language. It could be Rust, it could be C23, or something else entirely. But what it will definitely be is better structured. It would have clean, versioned APIs. And drivers will no doubt run in user space.
I’ve become convinced that complex things in tech either ossify and get stuff built on top of them, or get Ship of Theseus’d. It’s extremely rare for an outright replacement to replace something overnight. Linux is not going to be suddenly replaced by something incompatible, but I’m concinved it will become more oxidized over time. If not under Linus, then under an initially fully compatible corporate fork which would ultimately become more popular. So there’s some pressure on Linus to move it along .
All the Rust kernel developers have to know C. Is that true of the bigger maintainers who are arguing against it?
It’s fine to prefer one over the other.
If you haven’t learned one and refuse to try it and your argument boils down to “it’s not what we’ve done and I don’t want to change” that’s not good technical decision making.
> If you haven’t learned one and refuse to try it and your argument boils down to “it’s not what we’ve done and I don’t want to change” that’s not good technical decision making.
It sounds reasonable - you don't waltz into a large existing project $FOO and tell the existing maintainers "Here's our rules going forward - you shall learn $BAR!"
It's both rude and arrogant.
I have not seen any good arguments for why there should be an exception when $BAR == Linux and $FOO == Rust.
>but I will always wish people can just stop fighting, and work together.
Two separate ideas are conflated here.
It would make me happy if they stopped fighting, and instead worked separately on their C and Rust kernels respectively.