The subject is considerably more complex and nuanced than expressed by these one or two (obviously frustrated) people. I won’t presume to capture all the issues, but this person on HN does a decent job of capturing some of them:
You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors.
That this discussion repeats itself can only be taken to be either:
Evil C programmers are stodgy and old, and can’t/won’t get with the program, boo!
The Rust minority has, as of yet, failed to properly answer what happens when C APIs change in either signature or semantics, either of which can break the Rust bindings. Some questions:
Who tests to avoid this?
Who’s expected to fix it? The one changing the C code, who might not know Rust or a separate bindings team?
Is there a process ? A person to contact/raise the issue with? To get help or to have the work done?
What happens if the bindings cannot be fixed in time for the next Kernel release? Put differently, will Rust bindings changes hold back changes to the C code?
If broken bindings indeed can hold back changes, then C changes are held back by Rust and indeed then the onus is on the committer to either forego improving/evolving the C API or pick up Rust and fix the bindings also. In that case, yes, the Rust bindings will either freeze the C API or force the individual contributor to learn Rust.
That people repeat their concerns isn’t an expression of stupidity any more than a result of the people driving Rust into the kernel have yet to properly communicate how they envision this process to work, I suppose.
And then there is this angle, which also exists:
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.
The vibes I got in the other thread about Wedson’s announcement is that the concerns may be valid but there are indeed a handful of contributors who are aggressively shouting down Rust contributor’s efforts to set up the processes you outlined based on hard prejudice. The video Wedson posted was hard to watch. From the outside looking in it looks to be way more about ego than any particular technical roadblock.
Furthermore Lina’s concerns here are only broader what you are saying:
When I wrote the DRM scheduler abstractions, I ran into many memory safety issues caused by bad design of the underlying C code. The lifetime requirements were undocumented and boiled down to “design your driver like amdgpu to make it work, or else”.
My driver is not like amdgpu, it fundamentally can’t work the same way. When I tried to upstream minor fixes to the C code to make the behavior more robust and the lifetime requirements sensible, the maintainer blocked it and said I should just do “what other drivers do”.
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).
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.
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.
If rust code relies on a C API (as it necessarily does), then a breaking change to the API requires changing that rust code. This is common sense.
If a process is set up for deferring rust maintenance to a rust developer, this can only last as long as rust maintainers are willing to staff it.
If C developers are unwilling to accept any risk of needing to touch rust code in the future, then rust contributions should not have been allowed in the first place.
Allowing rust contributions and then imposing restrictions on what can be done with it? That’s not reasonable.
i can definitely see it as a “hostile takeover” of sorts, but this is something the project has decided on, for better or worse. i can understand not wanting to learn a new language that you may not like or agree with, but that means you will have to divest yourself from a project that adopts that language to a certain extent. Rust is—again for better or worse—something Linus thinks is good for the project, and thus learning Rust at least enough to not break the builds is a requirement for the project. i can’t imagine working on a software team where a chunk of people refuse to take part in a major portion of it simply because they’re not immediately familiar with it. that does sound like old crotchety behavior. on the other hand it’s tragic that so many people with all this experience are being forced into a design decision that arguably may have been made hastily and that they had little say in.
that makes this definitely an old guard vs new issue. and maybe it is an olive branch for the old guard to say “let’s just take our time with this.” but we have crossed a threshold where seeing a new project in C is the oddity while new projects in Rust are commonplace. Rust is mainstream now, and “i don’t want to learn this” is a dogshit technical justification.
Rust is—again for better or worse—something Linus thinks is good for the project, and thus learning Rust at least enough to not break the builds is a requirement for the project.
That misrepresents the situation. Linus accepted Rust provisionally, and only into certain parts of the kernel (drivers). It’s more of an experiment than what you wrote would suggest.
Rust is mainstream now,
Rust is highly visible now, due in no small part to its deafening evangelism. But it is not remotely mainstream in the sense of being a prevailing language, nor in the sense of being representative of the majority. It brings to the table a novel way to solve certain problems, and that is useful, but let’s not mistake that as the only way or those as the only problems.
Rust is mainstream now, and “i don’t want to learn this” is a dogshit technical justification.
i’m not really here to advocate for Rust in the kernel. i will say that i work on Rust professionally at a Fortune 100 company that is in the process of adopting it, which may skew my perception of it as mainstream, just to get the bias out of the way.
it is part of the project though, no? drivers still need to be interfaced with. so the people working on driver interfaces should be comfortable with it, again at least to preserve basic builds and do basic code review. this is specifically in reference to the issue that this thread is ostensibly started from: a kernel dev was getting worked up about “having to learn Rust”. so no, i don’t think it’s a strawman to point out the real people denying or frustrating patches just because they don’t understand the language. overly harsh maybe but not a total mischaracterization.
Your perspective makes more sense when you put it that way.
I think it’s important to understand that “having to learn Rust” is a proxy for “having to learn, become proficient in, become expert in, commit to regularly using, and take on the additional work of managing bindings between a large continually changing codebase and Rust, with no foreseeable end”. Multiply that by the number of kernel developers who would be affected, and remember that Rust in particular is famously time-consuming and (at least for some) often painful to use.
It’s not, “I don’t want to learn this”. (The people maintaining the kernel surely learn new things all the time in the course of their work, after all, as do most advanced programmers.) It’s more like, “I cannot reasonably take on such an enormous additional workload.”
The Rust camp in this disagreement doesn’t seem to grasp that yet. If everyone involved figures out a way to bridge that gap, I expect the frustrations will go away.
The thing here is that (even with things like the vfs interface), linux doesn’t have internal SPIs.
The friction here is that the rust devs want to write down the semantics in a formal fashion, and the C devs are used to a world where the semantics are implicit in the C code.
I thought the engagement in the video was the kind of useful feedback that was needed and asked for: “I’m not sure the semantics of this specific interface are precisely that,” which might have been out of place, but getting detail-focused feedback to an example is what you are going to have to expect from people who fit the role of VFS experts.
Ted was being an unconscionably rude fucker, but - diatribe aside - his process question is a reasonable one, although his solution “well you’re SOL” was poor, undiplomatic, and unhelpful.
Ted was being an unconscionably rude fucker, but - diatribe aside - his process question is a reasonable one, although his solution “well you’re SOL” was poor, undiplomatic, and unhelpful.
Maybe so. What I watched of the video had little surrounding context, though.
I’ve seen more than a few abrasive outbursts from people who care a lot about what they’re doing. When I see video of one, I try to keep in mind that they don’t often come out of nowhere. There’s a good chance that there was a much longer preceding exchange (perhaps not even in person) wherein the speaker had been trying to explain their perspective calmly and politely, but the other person was persistently missing it, due either to stubborn selfishness or to honest lack of understanding. Frustrated people sometimes resort to a blunt approach to try to get their message through.
In any case, I’m with you in noticing that important issues are being raised here. They’re not easy to solve, so it’s no surprise to see frustration along the way, but they still might lead to a good outcome.
Drew DeVault recently wrote up an idea similar to one that has been on my mind lately: What might come of a bunch of passionate Rust developers making a new kernel exposing Linux ABIs? It would be much faster and easier than a new kernel from scratch, because there’s already a working reference implementation in C. That seems like an effective way to work through design challenges without disrupting the existing system and development process, and once proven to work, might guide a better-defined path to integration with (or even replacement of) the C kernel. It would certainly have less friction than what we’re seeing now.
That’s an interesting notion (although it underestimates the effort, I think). Honestly, having machinery to write down contract semantics in a fashion amenable to automated proofs (meaning, does it type-check?) is massively promising; and I’m a dyed-in-the-wool C hacker. I would hope that the public exposure of this bad behaviour causes a few moments of self-reflection.
I suspect that attempting to chase a moving target of describing C apis with rust is just an avenue for burnout, unless there really is a mechanism for getting fixes back in the other direction, and professional respect flowing in both directions. That would be a massive shame, and an incredible missed opportunity.
It looks to me like there’s a bit of deadline ignoring going on, but even if it really is at heart reluctance to learn rust, aren’t a lot of linux developers volunteers? Getting cross that a bunch of volunteers don’t want to commit to permanently supporting rust (with its famously steep learning curve and famously hard to please borrow checker) seems a bit entitled to me.
“You there! Volunteers! Get on with doing exactly what I want exactly the way I want it and before you release your next version. Stop resisting the inevitable rise of your new priority: doing things our way. It’s better, so you’re wrong. Quickly now, stop resisting.”
Ah OK, yes. Then “Hey, Intel, Red Hat, Linaro, IBM and 500 other companies and a bunch of other people, You have to make this massive C project rust compliant otherwise you’re tech luddites.” It’s still entitled.
Personally I always think it’s weird when people expect open source authors to implement their preferences for them. Just stop acting like your priorities are inevitable. They’re not. Why should everyone else drop everything and do it your way, even if it is in your view obviously better?
The subject is considerably more complex and nuanced than expressed by these one or two (obviously frustrated) people. I won’t presume to capture all the issues, but this person on HN does a decent job of capturing some of them:
And then there is this angle, which also exists:
The vibes I got in the other thread about Wedson’s announcement is that the concerns may be valid but there are indeed a handful of contributors who are aggressively shouting down Rust contributor’s efforts to set up the processes you outlined based on hard prejudice. The video Wedson posted was hard to watch. From the outside looking in it looks to be way more about ego than any particular technical roadblock.
Furthermore Lina’s concerns here are only broader what you are saying:
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).
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.
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.
If rust code relies on a C API (as it necessarily does), then a breaking change to the API requires changing that rust code. This is common sense.
If a process is set up for deferring rust maintenance to a rust developer, this can only last as long as rust maintainers are willing to staff it.
If C developers are unwilling to accept any risk of needing to touch rust code in the future, then rust contributions should not have been allowed in the first place.
Allowing rust contributions and then imposing restrictions on what can be done with it? That’s not reasonable.
i can definitely see it as a “hostile takeover” of sorts, but this is something the project has decided on, for better or worse. i can understand not wanting to learn a new language that you may not like or agree with, but that means you will have to divest yourself from a project that adopts that language to a certain extent. Rust is—again for better or worse—something Linus thinks is good for the project, and thus learning Rust at least enough to not break the builds is a requirement for the project. i can’t imagine working on a software team where a chunk of people refuse to take part in a major portion of it simply because they’re not immediately familiar with it. that does sound like old crotchety behavior. on the other hand it’s tragic that so many people with all this experience are being forced into a design decision that arguably may have been made hastily and that they had little say in.
that makes this definitely an old guard vs new issue. and maybe it is an olive branch for the old guard to say “let’s just take our time with this.” but we have crossed a threshold where seeing a new project in C is the oddity while new projects in Rust are commonplace. Rust is mainstream now, and “i don’t want to learn this” is a dogshit technical justification.
That misrepresents the situation. Linus accepted Rust provisionally, and only into certain parts of the kernel (drivers). It’s more of an experiment than what you wrote would suggest.
Rust is highly visible now, due in no small part to its deafening evangelism. But it is not remotely mainstream in the sense of being a prevailing language, nor in the sense of being representative of the majority. It brings to the table a novel way to solve certain problems, and that is useful, but let’s not mistake that as the only way or those as the only problems.
That is a straw man.
i’m not really here to advocate for Rust in the kernel. i will say that i work on Rust professionally at a Fortune 100 company that is in the process of adopting it, which may skew my perception of it as mainstream, just to get the bias out of the way.
it is part of the project though, no? drivers still need to be interfaced with. so the people working on driver interfaces should be comfortable with it, again at least to preserve basic builds and do basic code review. this is specifically in reference to the issue that this thread is ostensibly started from: a kernel dev was getting worked up about “having to learn Rust”. so no, i don’t think it’s a strawman to point out the real people denying or frustrating patches just because they don’t understand the language. overly harsh maybe but not a total mischaracterization.
Your perspective makes more sense when you put it that way.
I think it’s important to understand that “having to learn Rust” is a proxy for “having to learn, become proficient in, become expert in, commit to regularly using, and take on the additional work of managing bindings between a large continually changing codebase and Rust, with no foreseeable end”. Multiply that by the number of kernel developers who would be affected, and remember that Rust in particular is famously time-consuming and (at least for some) often painful to use.
It’s not, “I don’t want to learn this”. (The people maintaining the kernel surely learn new things all the time in the course of their work, after all, as do most advanced programmers.) It’s more like, “I cannot reasonably take on such an enormous additional workload.”
The Rust camp in this disagreement doesn’t seem to grasp that yet. If everyone involved figures out a way to bridge that gap, I expect the frustrations will go away.
The thing here is that (even with things like the vfs interface), linux doesn’t have internal SPIs.
The friction here is that the rust devs want to write down the semantics in a formal fashion, and the C devs are used to a world where the semantics are implicit in the C code.
I thought the engagement in the video was the kind of useful feedback that was needed and asked for: “I’m not sure the semantics of this specific interface are precisely that,” which might have been out of place, but getting detail-focused feedback to an example is what you are going to have to expect from people who fit the role of VFS experts.
Ted was being an unconscionably rude fucker, but - diatribe aside - his process question is a reasonable one, although his solution “well you’re SOL” was poor, undiplomatic, and unhelpful.
Maybe so. What I watched of the video had little surrounding context, though.
I’ve seen more than a few abrasive outbursts from people who care a lot about what they’re doing. When I see video of one, I try to keep in mind that they don’t often come out of nowhere. There’s a good chance that there was a much longer preceding exchange (perhaps not even in person) wherein the speaker had been trying to explain their perspective calmly and politely, but the other person was persistently missing it, due either to stubborn selfishness or to honest lack of understanding. Frustrated people sometimes resort to a blunt approach to try to get their message through.
In any case, I’m with you in noticing that important issues are being raised here. They’re not easy to solve, so it’s no surprise to see frustration along the way, but they still might lead to a good outcome.
Drew DeVault recently wrote up an idea similar to one that has been on my mind lately: What might come of a bunch of passionate Rust developers making a new kernel exposing Linux ABIs? It would be much faster and easier than a new kernel from scratch, because there’s already a working reference implementation in C. That seems like an effective way to work through design challenges without disrupting the existing system and development process, and once proven to work, might guide a better-defined path to integration with (or even replacement of) the C kernel. It would certainly have less friction than what we’re seeing now.
https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-revisited.html
That’s an interesting notion (although it underestimates the effort, I think). Honestly, having machinery to write down contract semantics in a fashion amenable to automated proofs (meaning, does it type-check?) is massively promising; and I’m a dyed-in-the-wool C hacker. I would hope that the public exposure of this bad behaviour causes a few moments of self-reflection.
I suspect that attempting to chase a moving target of describing C apis with rust is just an avenue for burnout, unless there really is a mechanism for getting fixes back in the other direction, and professional respect flowing in both directions. That would be a massive shame, and an incredible missed opportunity.
It looks to me like there’s a bit of deadline ignoring going on, but even if it really is at heart reluctance to learn rust, aren’t a lot of linux developers volunteers? Getting cross that a bunch of volunteers don’t want to commit to permanently supporting rust (with its famously steep learning curve and famously hard to please borrow checker) seems a bit entitled to me.
“You there! Volunteers! Get on with doing exactly what I want exactly the way I want it and before you release your next version. Stop resisting the inevitable rise of your new priority: doing things our way. It’s better, so you’re wrong. Quickly now, stop resisting.”
No, the vast majority of linux developers are professionally employed to do it.
Ah OK, yes. Then “Hey, Intel, Red Hat, Linaro, IBM and 500 other companies and a bunch of other people, You have to make this massive C project rust compliant otherwise you’re tech luddites.” It’s still entitled.
What you describe would, indeed, be risible. Fortunately it’s merely histrionic twaddle.
Personally I always think it’s weird when people expect open source authors to implement their preferences for them. Just stop acting like your priorities are inevitable. They’re not. Why should everyone else drop everything and do it your way, even if it is in your view obviously better?
I mean, if you mean “Rustplaining is commonplace”, yeah.