Comment by steveklabnik
1 day ago
> I don't think that's true though, given the Linux development model where all internal APIs are private and unstable and can be changed at any time
Others have pointed out that this is mistaken, but also, it's in the link itself:
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: 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.
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings.
I wasn't mistaken; this is exactly what I thought. The problem is that Rust developers aren't magical genies who you can summon to fix Rust code. In the real world they are volunteers who might be busy, on holiday, no longer interested, dead, etc. What do C maintainers do when the Rust genies don't magically appear and fix their code? Just break the Rust code? That's obviously not a good long term solution.
So while I totally disagree with the C developers - they should just learn Rust! - I don't think you can get around this point by just hand-waving "don't worry about it; someone else will fix the Rust code". Maybe in the very short term, but not in the medium term.
> The problem is that Rust developers aren't magical genies who you can summon to fix Rust code
Linus will release a broken Rust kernel. Literally that has happened before in an indirect way because it was the holidays and a patch was not merged, but was explicitly told that the only reason why it wasn't merged was because the holidays made tracking the issue harder.
Also, every new piece of code has to enter linux-next.
There are at least six people whose full time employment is working on Rust for Linux, across a few companies. That scenario won’t happen.