Finding people willing to review rust must be much easier than finding someone willing to review c.
Actually I think the answer is yes, as Rust is much stricter to the person who's contributing the code. If I was asked to review another person's code, I would much prefer reviewing Rust code, as I would be able to concentrate on the logic and the efficiency of the code instead of potential low level mistakes.
The code smell in Rust is usually marked with ,,unsafe'', Boxing / reference counters, or dynamic behaviour, which is very easy to search for.
Is reference counters really a smell? I thought it was the main way to write Rust when the borrow checker is too strict for something you want to do.
Vec + generational indices might be the other way, is that preferred over Rc?
,,when the borrow checker is too strict for something you want to do''
Most of the times it isn't. Just as an example here's a random part of serde, the high quality serialization library in Rust:
https://github.com/serde-rs/serde/blob/master/serde/src/priv...
The amount of extra automatic memory management is often a good indicator of not well thought out data structures (although of course they are not always needed).
I guess your point is that c is harder to review?
But I suspect there are probably more people who are experts in device driver code and know kernel internals than all people who know rust.
"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."