Comment by armchairhacker
10 months ago
I've heard "Linus Torvalds has refused to decide whether to accept or reject Rust, and this is a leadership failure".
Maybe I'm don't know the situation enough, but I think he's not deciding because he has no idea. The "wrong" option may create far more consequences than the "right" one (so he can't e.g. flip a coin) but he has no idea which is "right".
Torvalds has spent so long working with C, even if he went out of his way to learn Rust, he'd never have as much experience to get an unbiased view of both. Perhaps he's hoping people who are younger and have more equal experience, but who are still smart and experienced, will shift the project towards the correct decision. Unfortunately that's not happening, because as a solid BDFL, he's the only one who can make a shift of that size. But either shift could be a huge stain on Linux's history, and he has no idea which, so he's stuck in a horrible conundrum.
If that's the case, keeping in mind that Linux is Torvalds's life's work, even if doing nothing is itself a bad choice, I don't blame him.
Regardless, since Torvalds can't decide, I think the community has to come together and 1) agree on a consensus mechanism then reach a consensus (e.g. vote on it), or 2) come up with a magic third option which Torvalds can accept*.
e.g. "integrate Rust into the kernel, but ensure that all future Rust compatibility issues are handled by Rust developers, even if they are caused by C code changes, through the commitment of a team of general-purpose Rust developers large enough relative to the number of C developers". I don't know if one can really ensure there are enough Rust developers to not block the C developers, but Rust is very popular and maybe growing faster than C, so maybe it's possible.
> "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.