They are amazing but at the end of the day they are still humans and they can make mistakes. In the YouTube video referenced one of the C devs is heavily against rust.

Decided to go look for CVEs from code the guy manages (Ted Ts'o) I found these

CVE-2024-42304 — crash from undocumented function parameter invariants

CVE-2024-40955 — out of bounds read

CVE-2024-0775 — use-after-free

CVE-2023-2513 — use-after-free

CVE-2023-1252 — use-after-free

CVE-2022-1184 — use-after-free

CVE-2020-14314 — out of bounds read

CVE-2019-19447 — use-after-free

CVE-2018-10879 — use-after-free

CVE-2018-10878 — out of bounds write

CVE-2018-10881 — out of bounds read

CVE-2015-8324 — null pointer dereference

CVE-2014-8086 — race condition

CVE-2011-2493 — call function pointer in uninitialized struct

CVE-2009-0748 — null pointer dereference

Do you see a pattern in the type of error here? It's pretty much entirely memory related and right in the wheelhouse of something rust would just outright not allow short of just slapping everything into unsafe blocks.

The Old Guard is not perfect, and they are acting as a barrier to new talent coming in. Sometimes change is good and I'm heavily in the camp that rust one of those times. Linus seems to agree as he allowed the code into the kernel which he would never do lightly or just because it's fomo

But on the other hand you can’t expect some smaller and smaller subset of the population to primarily just learn C and meet the criteria of a kernel dev.

I absolutely agree with all your points, and most rust devs would agree, but the general idea is that over time that energy (which would have been spent tweaking malloc and such) should be spent on the rust compiler and memory management systems, which is already magic as someone who as written a lot of c, c++, and spent the better part of a year learning rust. (I’m no expert of course, but I have a pretty decent grasp on the low level memory management of both the Linux kernel and the rust compiler).

So that over time the effort that would be spent on memory management and kernel functionality can be properly divided. Rust not being efficient somewhere in catching memory faults or managing memory? Fix it. Someone writing unsafe rust code? Fix it.

I think at the end of the day everyone wants the same thing which is a memory safe kernel, and I think that rust Is being shoehorned into kernel projects too early in places where it shouldn’t be, but I also think there is unnatural resistance to it just because it’s different elsewhere to "how it's always been done."

I guess the question is, what happens to the kernel when all the people who learned on C are gone? The majority of even the brightest new devs aren't going to cut their teeth on C, and will feel the same resistance to learning a new language when they think that there are diminishing returns to be had compared to what's new and modern and, most importantly, familiar.

I honestly get the hostility, the fast pace of technology has left a lot of older devs being seen as undesirable because the don't know the new stuff, even if their fundamental understanding of low level languages could be a huge asset. Their knowledge of C is vast and valuable, and they're working on a project that thrives because of it. To have new people come to the project and say "Yeah, we could do this without having to worry about all that stuff" feels like throwing away a lot of the skill they've built. I'm not sure what the solution is, I really don't think there are enough new C developers in the world to keep the project going strong into the future though. Maybe a fork is just the way to go; time will tell which is more sustainable.