Slightly off-topic but since the author mentions it; I personally cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary.

Since the kernel started, you can't begin to count the number of "better than C" languages that appeared.

Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago?

Zig, D, Ada, ... they all offer massive benefits over C.

The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be".

No regard for software that works great, the engineers that put time and effort into it to make it secure and fast, if its not Rust it must be broken.

Im excited to see the linux kernel improve even further, no matter what it takes, but it does rub me the wrong way and makes me stop and think a little bit when one particular language is held on such a gigantic pedestal.

I actually feel like Rust makes more sense for a kernel than user mode-apps. If there's any software that you want provable safety guarantees on, it's the kernel. What bothers me is the indiscriminate push to rewrite any and all user-mode apps in Rust. That one feels far less necessary to me in general, though there are exceptions obviously.

Rewrites in general are usually a terrible idea, unless the original is horribly broken (and beyond fixable).

If you wrote your app in C++, instead of rewriting it for the next decade in Rust just to get to the same point, slap some AddressSanitizer, ThreadSanitizer, -fanalyzer, cppcheck, etc. on it. You will get 98% of the way there.

Instead of spending 8+ years(!) rewriting[1] the GNU coreutils in Rust, you could spend half that time to ensure full coverage (branch-coverage, condition-coverage) in the existing ones. I will actually have a breakdown if someone tries to rewrite SQLite in Rust[2].

1: https://github.com/uutils/coreutils 2: https://sqlite.org/testing.html