[veidr]

Why do you guys keep saying he said this?? He did not say that, and you (and everybody else) can see it for yourselves:

> If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).

https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...

That's totally, utterly different than your characterization of it.

(So many other people were also falsely claiming that he said it like that, I initially assumed it was true, so I'm a little irritated.)

[intelfx]

Echoing @steveklabnik's words, you're just hanging up on the semantics of how a particular insult has been made. This does not refute or diminish the fact of an insult.

If I actively participate in and align myself with a community that is committed to doing the $thing, and you come and say to me that "$thing is cancer", or that "the fact of doing of $thing is cancer", then it's functionally equivalent to insulting this community, and by extension to insulting me. In other words, it's clearly supposed to make _me_ feel bad (for pushing $thing, or participating in the doing of $thing), regardless of the precise wording.

It's still an unprofessional, uncooperative, and _unreasonable_ thing to do.

[veidr]

Sorry; although I'm "on your side" in the sense that I want Rust in Linux and am bummed out that it seems increasingly like it's going to be a multigenerational slog, thanks to entrenched opposition from some of the C old guard, and which might even outlive Linux's window of viability.

But this is Linux kernel development. You just can't be such snowflakes, and so quick to be outraged. My mom died young, of cancer. I don't like cancer. I know that using "cancer" as a metaphor is a very negative way to characterize anything.

But the qualifier he added in the original statement is absolutely enough to make it a fair comment.

He really, really doesn't think using multiple programming languages is a sane approach. Would you really feel better if he said, "I think a multi-language approach is a very bad idea, it will inevitably spread, and it will end up causing systemic problems far away from this initial usage, and make the kernel increasingly frail and unhealthy over time" ?

If so, ... weird?

If not, then I think you are overreacting to the blunt (but technical, if perhaps motivated from some more emotional response) that he really doesn't like this idea at all.

"Cancer" is an appropriate shorthand to refer to a practice that you think causes systemic harm that compounds or grows worse over time. (I'm afraid I myself may have used it to describe PowerPoint presentations as the basis for meetings.)

I think his comment meets the minimal etiquette bar for a serious technical discussion. I mean, it wasn't nice. But the fact that he doesn't agree with you, or like your work, isn't an insult.

> He said "you are cancer, go away".

I find this absurd mischaracterization of what he said a lot more unacceptable than what he actually said. He's bluntly stating his technical opinion (which, again, I don't agree with). But you're not paraphrasing; you're basically lying.

[intelfx]

> Would you really feel better if he said, "I think a multi-language approach is a very bad idea, it will inevitably spread, and it will end up causing systemic problems far away from this initial usage, and make the kernel increasingly frail and unhealthy over time" ?

Yes, I absolutely would. Because this statement is neutral, specific, and technical (if unfounded, so I'd feel even better if such a statement would have been supplemented with justifications), therefore it can be attacked, argued, and refuted point-by-point on a technical basis. No such thing is possible when technical concerns are replaced with emotionally loaded metaphors.

So yes, I stand by my belief that saying "$thing is a cancer" when talking to someone who is good-faith committed to doing $thing is 1) unreasonable (because it cannot be reasoned with), and 2) an insult (because it is designed to appeal to emotions rather than facts).

[steveklabnik]

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.

[rc00]

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.

[steveklabnik]

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.

[rc00]

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

[steveklabnik]

> Will you feel this way when the ruling eventually comes down that the Rust for Linux experiment has been declared a failure?

Yes. What Linus says goes. That's how Linux works.

> Referring to what is currently an experiment as a decision is a rather bold misrepresentation of the current state.

It has been decided that having Rust in tree currently is acceptable. That is not a misrepresentation.

> Unstable infrastructure becoming a bottleneck is project management?

That is not the argument, it is a reason the argument is being made. The argument being made is "Linus should not have allowed Rust in the codebase." That there are technical consequences to project management decisions is not surprising, and they can be good or bad, but it's not the direct objection here, it's a reason why the objection is being made.

> That would have precluded the years of furor this has otherwise caused.

He himself said that he is unilaterally opposed, full stop, and nothing will change his mind. The state of Coccinelle wouldn't make any difference.

> You are operating on the belief and trust of the small amount of Rust developers.

I am taking Linus at his word.

[veidr]

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

[steveklabnik]

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.