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