> We do not have enough maintainers. We do have a lot of people who write code, we have a fair number of maintainers, but... it's hard to find people who really look at other people's code and funnel that code upstream all the way, eventually, to my tree... It is one of the main issues we have.
If I read this correctly, they have a lot of contributors, but few people willing to follow through with the code so it gets all the way up to Linus' tree. I don't see how rust would really help there.
It could be. Maybe there will not be more reviewers, but the process of reviewing could be faster. For example, in the kernel there are inline functions, which accept a constant (known at compile time) integer argument, and they make a switch or loop over that integer. The trick is to force compiler to inline function and to throw away most of switch's cases, or unroll loop completely, or make some other optimizations based on knowledge of the passed integer value.
Such a functions are exported to a public kernel API sometimes. So any kernel developer could call them. It make unavoidable a mistake of a programmer, when some of those functions was called with an unknown at compile time integer value. It is not a bug as it is, code would compile and work nevertheless, code would be bigger that it could be, maybe slower, that's all. But reviewer should be finding such a misuse of API.
It is just one example, linux kernel uses a lot of tricks and exposes it via APIs, reviewer must be aware of all of them and to check everything by itself.
Compare it with Rust. In rust one can encode a lot more limits on the right use of an API than in C. Encode and enforce. Even when rust sometimes cannot do it, rust have nice macros, instead of C's macro-horror. So a lot of mistakes that could be made with C, could be avoided with Rust. So it would be easy to review code, it would take less time from a reviewer to review code.
