Linux

From Linus's reply:

Honestly, what you have been doing is basically saying "as a DMA maintainer I control what the DMA code is used for".
And that is not how any of this works.
What's next? Saying that particular drivers can't do DMA, because you don't like that device, and as a DMA maintainer you control who can use the DMA code?
That's literally exactly what you are trying to do with the Rust code.
You are saying that you disagree with Rust - which is fine, nobody has ever required you to write or read Rust code.
But then you take that stance to mean that the Rust code cannot even use or interface to code you maintain.
So let me be very clear: if you as a maintainer feel that you control who or what can use your code, YOU ARE WRONG.

and

So this email is not about some "Rust policy". This email is about a much bigger issue: as a maintainer you are in charge of your code, sure - but you are not in charge of who uses the end result and how.

100% agree. No one should think they're entitled to be doing that.

Nice bit of spicy Linus to start the day.

Good though, these dinosaur maintainers really need to wind their necks in. From what I've seen so far, Rust is the best tool for the job in the situations where it's been used. I struggle to see anything more from the detractors than a toddler tantrum about having to learn a new language—particularly given the current situation where they've been treated with kid gloves and are allowed to ignore it entirely.

I like it that Linus stands his ground here. Hope that rust brings in more developers.

For those who failed to read TA, Linus appears to finally have read the PR and decided that what was indeed submitted was client code. No, he's not forcing subsystem maintainers to adopt Rust; he's saying they can't object to clients using Rust.

The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL.

"The document claims no subsystem is forced to take Rust"

that is very much true.

but as a result they also won't have any say on what goes on on the Rust side.

there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.

If you don't want to deal with the Rust code, you get no say on the Rust code.

I didn't read the patches, but what I see is that Linus believes that the original objection to the PR was wrong. He's asserting that subsystem maintainers who choose to not interact with client code get no say in whether the code is merged or not.

What he's not saying is that subsystem maintainers have to start including Rust in the subsystems; this isn't Linus forcing people to adopt Rust.

What I find most interesting about this is the whole premise of allowing Rust into the main tree. I'm sure there was a process, but does that mean now the wedge is in the door and people can start arguing about including Haskell? It would seem to me that once you make an exception, your argument for rejecting other languages becomes weaker. Why not Ada? It's at least as memory safe - if not more - than Rust. Haskell programs can be provably correct, and there are tools for these proofs. This is an even more powerful argument for Haskell over Rust - it's as memory safe, but also provide Curry-Howard correspondence, which Rust doesn't. Is it a popularity contest? What about Zig, which is in the Rust ballpark for safety, but vastly superior compile times (and, arguably a more simple mental model)? Odin? These are all type-safe, compiled languages without a runtime (hence, no Go).