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?
That seems like a non sequiteur. Did you watch the video? Did you hear what the presenter was asking for? Technical feedback on the API semantics they were describing. A heads-up if breaking changes to those APIs were about to land, so they can update bindings. They were bending over backwards to be accommodating. None of this is the entitled behaviour you describe.
I watched the video. The presenter is explaining how it’s really helpful to encode the semantics in the type system and the co presenter was talking about how algebraic data types are great for this kind of stuff. They wanted the C guys to agree a semantics for some file system api stuff, but some of the C folks were very reluctant to commit to a semantics that they weren’t convinced covered all the edge cases and that was going to be encoded using concepts they’re unfamiliar with and syntax that looks alien to them.
The whole “but look at all the guarantees this gives you, see how much effort and worry the compiler now handles for you, and how while classes of bugs simply cannot happen!” thing is stuff people have been saying to the C programming community for well over three decades. It didn’t wash with them then, why would it wash now?
Pascal advocates said “look how the compiler does array bounds checking for you, you need never segfault again” and the C programmers said “yeah, your program quits with a pretty and polite message about how it ran out of space and mine segfaults, but mine runs twice as fast as yours and your syntax is stupid, I’m sticking query my curly braces.”
Lisp programmers said “macros? Those aren’t macros. You have no idea what power real macros have. Imagine if your code could edit itself!” and the C programmers said “that meant parens would give me RSI and my code runs five times as fast as yours.”
Pure functional programmers have been extolling the virtues of algebraic data types (and immutability by default, and automatic memory management) for decades, but the C community has never wanted to know, why would they now?
The C community heard all these ideas, and all these lovely guarantees, and has repeatedly said “See those guard rails at the bowling alley? I don’t use them. They’re for people who aren’t good at bowling. If you want a big guiding abstraction that really works in practice, here it is: everything is just a stream of bytes. Simple, effective and FAST.”
Expecting compiler guarantees and memory safety to win round a C programmer or someone that’s into dynamic types is like expecting a motorbike rider to trade their bike for a pickup truck on the grounds that it’s so roomy and robust. They’ve never wanted that. It’s a massive, massive culture clash that the rust folks don’t see at all, because they know they’re right, they’ve seen the light, they know the truth, and it’s fast and fast enough for full on systems programming so they’re in the same club as the C folks, but the C folks didn’t want to be saved from C because they never weighed the risks as high as other folks did.
It reminds me of two Republican women whose children were badly traumatised in a genuine active shooter crisis at their school, and they realised that they’d been downplaying it and that actually this was a really serious issue that needs fixing, but they were very surprised, baffled and hurt that their Republican friends, councillors and law makers didn’t realise like they did how important this stuff was and continued to downplay it as if the children’s trauma was somehow less important than their friends political beliefs.
Summary: rust folks are very late indeed to the “aren’t compiler enforced guarantees great” party, and these C folks have been turning down invitations since forever. They’re going at it with missionary zeal to the very community that ignored 100% of the previous missionaries, and are surprised that they’re getting so much push back and resistance to what they feel so inevitably has to happen in the end and so clearly the Right Thing.
C is where the people who love the speed and freedom of manual memory management hang out. Why would anyone expect a 35 minute talk to change all of that?
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?
That seems like a non sequiteur. Did you watch the video? Did you hear what the presenter was asking for? Technical feedback on the API semantics they were describing. A heads-up if breaking changes to those APIs were about to land, so they can update bindings. They were bending over backwards to be accommodating. None of this is the entitled behaviour you describe.
I watched the video. The presenter is explaining how it’s really helpful to encode the semantics in the type system and the co presenter was talking about how algebraic data types are great for this kind of stuff. They wanted the C guys to agree a semantics for some file system api stuff, but some of the C folks were very reluctant to commit to a semantics that they weren’t convinced covered all the edge cases and that was going to be encoded using concepts they’re unfamiliar with and syntax that looks alien to them.
The whole “but look at all the guarantees this gives you, see how much effort and worry the compiler now handles for you, and how while classes of bugs simply cannot happen!” thing is stuff people have been saying to the C programming community for well over three decades. It didn’t wash with them then, why would it wash now?
Pascal advocates said “look how the compiler does array bounds checking for you, you need never segfault again” and the C programmers said “yeah, your program quits with a pretty and polite message about how it ran out of space and mine segfaults, but mine runs twice as fast as yours and your syntax is stupid, I’m sticking query my curly braces.”
Lisp programmers said “macros? Those aren’t macros. You have no idea what power real macros have. Imagine if your code could edit itself!” and the C programmers said “that meant parens would give me RSI and my code runs five times as fast as yours.”
Pure functional programmers have been extolling the virtues of algebraic data types (and immutability by default, and automatic memory management) for decades, but the C community has never wanted to know, why would they now?
The C community heard all these ideas, and all these lovely guarantees, and has repeatedly said “See those guard rails at the bowling alley? I don’t use them. They’re for people who aren’t good at bowling. If you want a big guiding abstraction that really works in practice, here it is: everything is just a stream of bytes. Simple, effective and FAST.”
Expecting compiler guarantees and memory safety to win round a C programmer or someone that’s into dynamic types is like expecting a motorbike rider to trade their bike for a pickup truck on the grounds that it’s so roomy and robust. They’ve never wanted that. It’s a massive, massive culture clash that the rust folks don’t see at all, because they know they’re right, they’ve seen the light, they know the truth, and it’s fast and fast enough for full on systems programming so they’re in the same club as the C folks, but the C folks didn’t want to be saved from C because they never weighed the risks as high as other folks did.
It reminds me of two Republican women whose children were badly traumatised in a genuine active shooter crisis at their school, and they realised that they’d been downplaying it and that actually this was a really serious issue that needs fixing, but they were very surprised, baffled and hurt that their Republican friends, councillors and law makers didn’t realise like they did how important this stuff was and continued to downplay it as if the children’s trauma was somehow less important than their friends political beliefs.
Summary: rust folks are very late indeed to the “aren’t compiler enforced guarantees great” party, and these C folks have been turning down invitations since forever. They’re going at it with missionary zeal to the very community that ignored 100% of the previous missionaries, and are surprised that they’re getting so much push back and resistance to what they feel so inevitably has to happen in the end and so clearly the Right Thing.
C is where the people who love the speed and freedom of manual memory management hang out. Why would anyone expect a 35 minute talk to change all of that?