> IMO its more like choosing a lesser known evil, because the new ones already demonstrated not being better.
First, I would disagree re: the 2nd part. Rust has obviously demonstrated itself, specifically in kernel space, but also almost everywhere else systems programming matters. I don't know what more it needs to do.
Second, why must we choose? I (and I think the R4L folks would agree) don't think it's necessary for us to choose between C and Rust, if you're simply writing drivers in Rust. The reason this seems like such a fit by Mr. Hellwig is that this is obviously premature. Why don't we see how it works first, before screaming about how it will never work.
> This whole Rust in Kernel will not end well.
Third, I think you may discount how important the Rust energy/mindshare is. If it's not Linux, it will be FreeBSD or some other kernel, and that will be where all the interesting kernel development will be happening in 10 years. FWIW, I'd much rather have arbitrary Linux binaries work on my Rust-y kernel 10 years from now, I'd much rather my cutting edge driver code works on a system we can use now, etc.
I hope this will usher in an era of less rudimentary kernel systems, because of how hard complex things in C are to get correct. For instance, OSS filesystem development has mostly stood still since ZFS. That is -- years later, bcachefs and btrfs are still chasing ZFS. Can you imagine a new filesystem, built for NVME and async IO, with ZFS feature parity, and additional wild features only available on enterprise storage (3D RAID anyone?, clustering, distributed filesystems...), which ships and becomes stable in years not decades?
Instead Linux users who prefer stability prefer to drive an antique, the equivalent of Porsche 356. Okay for its time, and for certain workloads fast, but only because it still lacks so much.