Comment by jodrellblank
10 months ago
> "but ensure that all future Rust compatibility issues are handled by Rust developers"
But how? One of these:
- The C developer needs to know enough Rust to know which changes will affect Rust, contact the Rust developers and explain the change and wait. Extra work and delay they do not want.
- The C developer does not need to know any Rust, but must be doing Rust builds, and if something breaks then contact the Rust developers and explain the change and wait. Extra work and delay they do not want.
- The C developer needs to explain every change to the Rust developers in case it might break, before they can do it. Extra work they do not want.
- The C developer ignores Rust, and the Rust developers must work with unpredictable shifting sands. This works for a while and the Rust codebase becomes larger and new Rust developers join. This is an unstable configuration. The larger the Rust codebase, the more disruptive any change could be and the new Rust developers will feel the changes are malicious, capricious, and will demand this stops and the changes are planned and communicated and the ground stabilises, or they get fed up and quit. Leading back to one of the above points - C developers either need to maintain the abandoned Rust code, or they need to do extra work of tracking, coordinating, explaining, running changes through another team and waiting for them, extra work they do not want, or they can't make certain changes in the C code base, a limitation they don't want.
Rust developers saying "we will do all the work" isn't enough because of the meta-work of organising and communicating the work.
Yeah, I don't think there's a solution, otherwise someone would've thought of it.
I'm now thinking the solution is "no Rust in the kernel, but we promise to revisit in X years" (then if in X years the picture isn't clearer, revisit in X more years). As someone who greatly prefers Rust, it's unfortunate, but the alternative adds lots of complexity (IMO more than Rust's type system removes) and that's too big an issue.
Moreover, the would-be-contributors who use Rust can (and IMO should) unite and fork the project, creating a "Rusty-Linux" which would be the base for many distros like Linux is the base for all distros. If the fork ends up higher-quality than Linux, especially if Rust adoption keeps growing and C usage starts shrinking, in X years (or 2X, or 3X, etc.) Rust will be so clearly beneficial that nay-sayers will be overpowered (or even convinced), and Rusty-Linux will become Linux.