Hacker News Reader

Comment by cycomanic | Hacker News Reader

The problem is, that he let's a maintainer say he is going to fight any Rust code getting into any "core" (whatever he considers core) part of the kernel, even if it's just a wrapper to make driver code more maintainable. I would say, that's a strategy decision that should not be up to any subsystem maintainer, that's a decision that should be up to Linus, by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers. I don't believe that was what the rust guys thought they'd be signing up for.

View on HN

> by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers

And let's not be obtuse, some of those subsystem maintainers are staunchly opposed, so "it's up to them" is obviously an indirect way of saying "no rust". I don't blame those maintainers for balking at a whole new very different language, but Torvalds has a choice of telling them either "suck it up, buttercup" or "I hear you; rust is gone". Instead, he's just letting things fester.

This seems like black and white thinking. There's a huge spectrum between

> "suck it up, buttercup" or "I hear you; rust is gone".

where various levels of compromise happens.

Maintainers are people and people can change their mind over time. If rust was a huge success in large parts of the kernel and you still had a few holdouts, sure, you could tell them to adapt or go away. In this early stage, it's kinda up to rust people to show that both they and rust can work in this setting

> that's a strategy decision that should not be up to any subsystem maintainer

So people are not allowed to hold positions and argue for them in public, or take actions that align with that position?

> I don't believe that was what the rust guys thought they'd be signing up for

It's not like there wasn't any existing precedence with C++, and many of the arguments I've read seem consistent with that history.

The C++ situation was completely different, Linus said from the get go "no way", thus nobody put serious work writing c++ code for the kernel. With Rust Linus essentially said let's see how it goes, but specifically said he would deal with maintainers who would be unwilling to consider code that would be necessary for R4L. Based on this people invested significant work into writing code that is quite widely used, only to now have a maintainer saying he'll oppose any Rust code coming into the kernel, and Linus saying the guys trying to get the code in are the problem.

> that's a decision that should be up to Linus, by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers.

And that's a perfectly resonable position.

Reply on news.ycombinator.com