Comment by steveklabnik
10 months ago
His reply after that: https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
> You might not like my answer, but I will do everything I can do to stop this.
10 months ago
His reply after that: https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
> You might not like my answer, but I will do everything I can do to stop this.
In the face of Coccinelle for Rust still being unreliable, can you blame him or any maintainer? The codebase is too large to suggest that manual intervention every time something breaks is acceptable, especially when the same automated tool has been in place for C for nearly two decades. And worse yet, much of the code that is generated for Rust is in the form of macros which are quite possibly some of the most unmaintainable and difficult to parse parts of Rust.
You might not like the response for being strongly worded but it is indeed backed by a technical stance and not a political or social one as has been repeatedly suggested. Already overworked maintainers are not willing to sign up for additional maintenance to what has been a solved problem. Objectively, no one should disagree with that stance.
Yes, I do think endlessly relitigating project decisions that have been made is inappropriate.
It is not a technical stance. It is a project management one.
> Objectively, no one should disagree with that stance.
That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.
> Yes, I do think endlessly relitigating project decisions that have been made is inappropriate.
Will you feel this way when the ruling eventually comes down that the Rust for Linux experiment has been declared a failure? Referring to what is currently an experiment as a decision is a rather bold misrepresentation of the current state. You want to present Rust in the kernel as a foregone conclusion when the reality couldn't be further from that.
> It is not a technical stance. It is a project management one.
Unstable infrastructure becoming a bottleneck is project management? Maybe a working implementation of Coccinelle for Rust should have been among the criteria before the experiment should have been allowed to proceed. That would have precluded the years of furor this has otherwise caused.
> That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.
This highlights the crux of the issue and the reason your bias is clouding your view of the issue objectively. You are operating on the belief and trust of the small amount of Rust developers. Reality is proving otherwise time and time again.
1 reply →
I know, and I in fact do not like his answer, and think he is wrong in general.
But he didn't say "rust is a cancer", "you are a cancer", "your work is a cancer", or the other permutations of that I've read in this long thread; that's what I was replying to.
His technical assessment doesn't make sense, and apparently isn't even his to make. So that can, and should be, rebutted and refuted. But not by distorting his words, by attacking the substance of it.
(Which I do acknowldge that you have been doing; I've read the entire HN thread, so kudos for that.)
He said
> (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
Where the cross-langauge in this case is Rust. Rust for Linux is creating a cross-language codebase. That means Rust for Linux is cancer.
> and not rust itself, just to escape the flameware brigade
is like when people say "I'm not trying to be rude, but" and then says an incredibly rude thing. Saying "I think this abstract idea is cancer, and you're the specific instance of this abstract idea, that doesn't mean I'm saying you are the thing" is incoherent.