Investing in automated C to Rust translation

CHERI doesn't exist (Morello isn't available) and memory tagging is not a thing on most processors (especially not server or embedded which are where most Linux runs). Apple's MIE needs Asahi to reach M5 which won't happen for some years, and ARM servers are still quite new.

Meanwhile, Rust structurally enforces memory safety. It's simply a better option than C in many cases -- C needs closer scrutiny, more third-party static and dynamic analysis, conventions differ much more wildly, far more expertise is required, the bar to safe contribution is much higher, code review is more difficult, I could go on and on but there are reasons to prefer Rust and it's not just cargo culting. Memory safety is a huge reason to want Rust, but also the type system, monomorphized generics, traits, the great first-party package manager and build system, better developer experience, clearer semantics, ... I could go on.

That said, there are also downsides to Rust, like hard reliance on LLVM, bad support for embedded or proprietary platforms, bad compile times, less flexibility in what is accepted by the borrow checker, more runtime checks and panics for safety, fragmented ecosystem, some basic things are "unstable", some semantics like pointer provenance still haven't been worked out after over a decade, semantics of borrowing are still in flux as well, bad interoperability with C++, etc.

Then there's the fanbase which can be absolutely insufferable, and show such zealotry that many people are turned away from Rust before even getting to honestly consider it, just because the fans can be so rabid.

These technologies are cool and good and useful but they do something different than Rust: they catch problems at runtime and mitigate the bad effects, rather than preventing them at compile time.