[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.

[snvzz]

>The most prominent one is supportive of Rust

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.

[nequo]

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.

[snvzz]

>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.

[iknowstuff]

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 .

[lelanthran]

> The most prominent one is supportive of Rust.

"supportive" is not a binary.

Interpreting "no immediate objections" as "this is what I want" is specious and intellectually dishonest.

[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.

[lelanthran]

> 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.

[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.

[topspin]

I'll stipulate your view of the proposal. Does an uncivil, almost hysterical reaction that is perceived (wrongly or otherwise) as elitist and irrationally hostile an effective approach?

I question the basis of the reaction and find it wanting. Paraphrasing now; "50 filesystems won't be instantaneously converted to Rust." Has anyone, anywhere suggested such a thing? I don't think anyone credible has done so. A strawman argument. The accusation of some forced conversion to a new "religion" is also baseless, not to mention insulting.

An aside: the get_or_create_inode method example that was left on the display for nearly half the presentation is very compelling to me. It is explicit and comprehensive: one can trivially comprehend both the likely implementation of the method and the obligations of the caller without reading a line of code beyond that declaration. Practically self documenting and vastly superior to conventional systems programming C. At one point a speaker likened this to Java, I suppose because of the type composition. That's ignorant and false: that signature conveys so much more value than what one sees in typical Java code that it's not in the same ballpark at all. The verbosity has actual value.

Rust is great; a legitimate advance in systems languages. People are compelled by it. That has produced some conflict. Not all conflict is avoidable or inherently evil. The C side of this conflict will need better tactics if they're not going to just devolve into irrationality with false claims, baseless accusations and hysteria.

[lelanthran]

> The C side of this conflict will need better tactics if they're not going to just devolve into irrationality with false claims, baseless accusations and hysteria.

The "C side" don't need any tactics; it's their project and they are free to refuse entry of some other group of people.

They can make false claims, they can make baseless accusations and they can throw hysterics all they want to, because they don't have to convince anyone of anything.

The Rust side has to provide an argument more compelling than "you are using inferior tools", because even if true, it's irrelevant!

The Rust side has to do the convincing here, not the C side.

[topspin]

This response goes back to my first post on the topic: such attitudes and behavior have led to successful forks of major components that ultimately subsumed the legacy work. The Rust side doesn't even have to go so far as to reimplement the entire kernel, as Drew proposes. They can simply fork, govern the evolution of the fork as they see fit, including whatever adaptations they prefer to accommodate Rust and, should their efforts yield a compelling product (to one or all of Google, AWS, Microsoft, et al.,) they can win.

Also, I don't believe the "C side" has the degree of control over all of this that you hypothesize. The Linux BDFL isn't anti-Rust, and he is endowed with an inhuman degree of wisdom that will likely prevent him from supporting irrational C dogmatists. The acceptance by Linus of a possible future that included Rust in the kernel is the start of all of this. He knew then the road would not be trouble free; he's been calling these kinds of shots for too long to imagine otherwise.