Mainlining memory safety improvements, in C, for C code should be welcomed and it is very concerning if she indeed got shunned because the end goal was to offer lifetime guarantees (which to my admittedly non-expert eye sounds like it would be a good thing for memory safety in general).
It would be a good thing. Nobody is debating that. It’s why Linus agreed to start experimenting with Rust in certain parts of the kernel.
However, trying to integrate one very specific approach to it into a large, already-working system that works quite differently, is a lot harder than writing from scratch one small component that mainly has to work in its own native ecosystem (as Lina has done).
Without good and realistic answers to how the long-term maintenance of such changes would be managed, it is myopically unrealistic to propose those changes, let alone to push this hard for them and be so dismissive of the folks who actually have the experience and responsibility to keep it all running. Especially when it’s something that the entire world has come to depend upon in one way or another, as is the case with the linux kernel.
The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover.
Seems like a moral panic over absolutely nothing (where are the Rust developers allegedly forcing people to learn Rust? all I’ve seen in these threads today is Rust developers asking for an open mind and a willingness to collaborate), and that the response to this “concern” is to block any and all changes that might benefit Rust adoption is really concerning (but unfortunately not unsurprising) behavior.
The problem isn’t the immediate thing they’re asking for; it’s the inevitable chain reaction of events that will follow. They don’t seem to understand the bigger picture, so they don’t have answers for how it would be managed. The obvious but unstated solution would be that many kernel developers would have to invest an enormous amount of time (which they might not have) to become proficient in Rust and adapt an enormous amount of surrounding code to it, on top of their existing responsibilities. More than a few people (who are very much in a position to know) see that as unviable, at least for now.
No viable alternative has been offered. Hence the objection. And, since the vocal minority keep on pushing for their changes without addressing the issues that have been raised, the only sensible response is to reject their request.
Without good and realistic answers to how the long-term maintenance of such changes would be managed, it is myopically unrealistic to propose those changes
Lina is talking about a minor change though. It challenges the dominant paradigm but her opinion seems to be that it doesn’t have negative impact on the overall maintainability. To shift the discussion to maintainability is whataboutism; if these kernels maintainers can’t accept patches that do not have a negative impact on maintainability or directly involve Rust in any way because they are related to Rust in general, that’s disappointing tribalism regardless of your opinions on Rust or Rust developers.
I might be missing some context here as I’m only going off what Lina has said, but if half of it is true then we need to shift attitudes before talking about how to integrate Rust in the kernel ecosystem. It certainly feels very disingenuous and retrograde to present Rust as some kind of existential threat rather than a novelty or opportunity, as if no combination of processes and tools could ever possibly overcome the stated maintainability challenges.
It would be a good thing. Nobody is debating that. It’s why Linus agreed to start experimenting with Rust in certain parts of the kernel.
However, trying to integrate one very specific approach to it into a large, already-working system that works quite differently, is a lot harder than writing from scratch one small component that mainly has to work in its own native ecosystem (as Lina has done).
Without good and realistic answers to how the long-term maintenance of such changes would be managed, it is myopically unrealistic to propose those changes, let alone to push this hard for them and be so dismissive of the folks who actually have the experience and responsibility to keep it all running. Especially when it’s something that the entire world has come to depend upon in one way or another, as is the case with the linux kernel.
The problem isn’t the immediate thing they’re asking for; it’s the inevitable chain reaction of events that will follow. They don’t seem to understand the bigger picture, so they don’t have answers for how it would be managed. The obvious but unstated solution would be that many kernel developers would have to invest an enormous amount of time (which they might not have) to become proficient in Rust and adapt an enormous amount of surrounding code to it, on top of their existing responsibilities. More than a few people (who are very much in a position to know) see that as unviable, at least for now.
No viable alternative has been offered. Hence the objection. And, since the vocal minority keep on pushing for their changes without addressing the issues that have been raised, the only sensible response is to reject their request.
Lina is talking about a minor change though. It challenges the dominant paradigm but her opinion seems to be that it doesn’t have negative impact on the overall maintainability. To shift the discussion to maintainability is whataboutism; if these kernels maintainers can’t accept patches that do not have a negative impact on maintainability or directly involve Rust in any way because they are related to Rust in general, that’s disappointing tribalism regardless of your opinions on Rust or Rust developers.
I might be missing some context here as I’m only going off what Lina has said, but if half of it is true then we need to shift attitudes before talking about how to integrate Rust in the kernel ecosystem. It certainly feels very disingenuous and retrograde to present Rust as some kind of existential threat rather than a novelty or opportunity, as if no combination of processes and tools could ever possibly overcome the stated maintainability challenges.