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.
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.