Kroah‑Hartman consistently framed language choices in terms of reviewer workload rather than developer convenience. Linux has “over 5,000 developers” but “about 150 core maintainers that review the majority of the code,” a skew that drives his priorities. “We optimize for reviewers. We don’t optimize for developers because we have a lot of developers,” he said, suggesting Rust’s ability to enforce locking and lifetime rules at build time means reviewers can spend their limited bandwidth on logic rather than bookkeeping: “If it builds as a reviewer, I know it’s OK. I can look at the logic.”
That’s a great point. Living open source code must be readable and maintainable. Rust is an excellent match for that.
I still understand the argument of the C greybeard to Rust knowledge gap though. Objectivity, it’s hard to argue for a spidey sense that took years or decades to develop vs a deterministic and strict compiler, but developer (and reviewer) experience often seems to be rooted in personal comfort* more than in language features.
That said, we all have to deal with transitions and learning consistently leads to better outcomes. The argument is sound, but the pragmatic dynamics may take some time.
*”personal comfort“ doesn’t mean the language or tools are somehow objectively comfortable, but that people feel good, confident, productive, and happy working with them. Just yesterday I was thinking that I like the Gir “is hard” - it stimulates my brain on a daily basis. Different people get that in different ways.
I still understand the argument of the C greybeard to Rust knowledge gap though.
The patterns that Rust enforces are usually good practice in concurrent C programs, too. Of course, there are things that you can express in C which Safe Rust would not allow - but the same is true for Assembly language. And this alone is little reason to use Assembly.
Yes, I agree completely, but we don’t have a bunch of Assembly diehards working on Linux, so the parallel - while accurate - feels out of scope.
Ultimately, it comes down to thoughtful transitions over a reasonable period of time.
It *is* convenient for developers, though, for pretty much the same reason: you don’t have to think as hard about locking and whatnot because the compiler is checking your work.
I’d say it’s a lot more convenient to write bad C than bad Rust. To put it another way, Rust shifts frustration left and can be disheartening for some people.
Yes, exactly. I’m trying to write good code, so I appreciate tools that make it inconvenient to write bad code.
