[yshui]

I am split on this. Maybe I am idealistic and naive, but I will always wish people can just stop fighting, and work together. Fragmenting the community and starting a project out of grudge, is always the last resort, IMO.

OTOH, I also recognize sometimes it is really that bad and going your own way is the best thing to do. But I think Linux isn't at that position yet.

[snvzz]

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.

[steveklabnik]

> including those most prominent,

The most prominent one is supportive of Rust. And traditionally when it comes to technical decisions, it is his opinion that matters most.

[MBCook]

Prefer C? Or haven’t used Rust?

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.

[topspin]

> starting a project out of grudge

How many times has this succeeded for fundamental work? I can think of a couple, including Xorg and GCC. I don't know if those cases can be characterized as "grudges" exactly but, in each instance, someone was unsatisfied with the prevailing conditions, forked the work, and then subsumed the legacy.

Doubtless there have been far more failures than successes. I also know that computing probabilities based on such ratios is simple minded: other factors exist and the equation is non-linear.

> But I think Linux isn't at that position yet.

I was disturbed by the irrational behavior I saw in this talk[1]. What the presenter sought was reasonable: communicate the intended semantics so Rust kernel developers can track the evolution. This was somehow understood as: forego C and become a Rust programmer, take responsibility for our work and maintain it going forward.

No, I do not believe the former implies the latter. There are endless silos, both formal and informal, for both good reasons and bad reasons, permeating all intellectual work, whether "open" or not. It is entirely reasonable to imagine that this pattern can be employed among reasonable people for the matter at hand, especially for something like file systems, where even parallel implementations can and do exist simultaneously.

If this behavior is prevalent enough then drastic steps are justified. Whether they're feasible or not is another matter, and also a many factored, non-linear calculation. One could, for instance, reimplement only some fraction of the kernel and be entirely sufficient for most of the backend cloud server Linux use case. Given the enthusiasm for Rust among major cloud operators, I suspect this might be attempted at some point.

[1] https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1566s

[lelanthran]

> This was somehow understood as: forego C and become a Rust programmer, take responsibility for our work and maintain it going forward.

That's how I understand it as well: the proposal is

1. Put our Rust code in.

2. If you make C-code changes that break Rust-code, then your change can't be merged until you either learn Rust or wait on us to fix things.

This is an unreasonable expectation, IMO, for any large project written in any language; this is not specific to Linux and C and Rust.

Making unreasonable proposals in civil language does not magically turn that proposal into a reasonable one.

Pressing forward in spite of feedback that the proposal is unreasonable is uncivil, even if you spread a thin veneer of civility over it.