Doesn't this mean that the change will have to be blocked until the Rust side is also fixed? Rust folks are eager to do it now, and there's a lot of "hype" around having Rust but is it going to be the same in, say, 15 years?
Userspace Rust is awesome ( aside from being a bit big), but I don't know if Rust in the kernel is proven yet (Time will literally tell).
You would think that by then either the Rust experiment has failed or the project has gained enough experienced developers such that maintaining such large refactors is feasible beyond heroics of the RfL folks. Either way it would be unlikely to be a problem then.
But in the meantime, how is the Linux project meant to evaluate what the maintenance burden is or wether the benefits outright the costs if the kernel maintainers doing the RfL work are being repeatedly stonewalled?
Comments
Doesn't this mean that the change will have to be blocked until the Rust side is also fixed? Rust folks are eager to do it now, and there's a lot of "hype" around having Rust but is it going to be the same in, say, 15 years?
Userspace Rust is awesome ( aside from being a bit big), but I don't know if Rust in the kernel is proven yet (Time will literally tell).
You would think that by then either the Rust experiment has failed or the project has gained enough experienced developers such that maintaining such large refactors is feasible beyond heroics of the RfL folks. Either way it would be unlikely to be a problem then.
But in the meantime, how is the Linux project meant to evaluate what the maintenance burden is or wether the benefits outright the costs if the kernel maintainers doing the RfL work are being repeatedly stonewalled?
No. It specifically is being treated as a second class citizen that is allowed to break.
Rust is already in the Windows kernel. It’s being used in embedded devices and kernels in production. It has proven itself.