4 ms·
> Learning and mastering a new language and applying it to an existing code base is quite a lot of work. That takes a lot of time away from other things they mi
by bryanlarsen 2y ago
> Learning and mastering a new language and applying it to an existing code base is quite a lot of work. That takes a lot of time away from other things they might be working on.
Nobody is asking them to do that. They are being asked to review C patches to enable Rust-in-Linux.
> I think these are mostly (overwhelmingly?) volunteers, so you can't just assign them work
The vast majority are professionals. A few work for the Linux Foundation, many work full time on Linux inside of big corps. For example, Ted T'so works for Google.
- jorams 2y ago> Nobody is asking them to do that. They are being asked to review C patches to enable Rust-in-Linux. My understanding of their issue is that this can't really be true. Any C code that affects Rust bindings in any way (which will be more and more as long as the integration grows) will become impossible to change without either knowing Rust or hoping/waiting for someone else to pick up that part.
- steveklabnik 2y agoThey are repeating this as if it’s true when it’s been explained that it is not. The Rust for Linux people have committed to picking it up. They don’t even have to wait for them to do that work before merging, though they did ask if they could get a heads up email so the turnaround time would be faster.
- jmull 2y ago> The vast majority are professionals. That’s good to know. But I guess the money is coming from a bunch of different companies/management structures, so you probably still can’t just tell everyone what to do. > Nobody is asking them to do that. Perhaps not now, but I don’t think anyone thinks or claims the ambition for rust in linux is for rust to stay on the fringes and out of the way (otherwise, why even bother?). The more rust there is in the kernel, the more likely it is a linux dev will either need to master rust or make way for someone who will.