Automated transforms like this seem risky at best and dangerous at worst, due to one fundamental truth about computer software: garbage in, garbage out.
The transform can be perfectly correct, but any bugs in the input will be translated along with the rest.
Yet, I somehow doubt translation will be perfect, in that same way that translations among spoken languages have idioms that never quite carry across their full meaning.
So, yes, this can “reduce the risk”, but the nature of the tool seems to carry high inherent risk. I would hope no one tries to vibe this kind of transformation on a large legacy production code base without giving the results a line-by-line audit.
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.
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.
Automated transforms like this seem risky at best and dangerous at worst, due to one fundamental truth about computer software: garbage in, garbage out.
The transform can be perfectly correct, but any bugs in the input will be translated along with the rest.
Yet, I somehow doubt translation will be perfect, in that same way that translations among spoken languages have idioms that never quite carry across their full meaning.
So, yes, this can “reduce the risk”, but the nature of the tool seems to carry high inherent risk. I would hope no one tries to vibe this kind of transformation on a large legacy production code base without giving the results a line-by-line audit.
"If we want more systems software to benefit from memory safety, we need better ways to reduce the cost and risk of migration."
What about using CHERI or Memory Tagging? Rewriting an established and mature codebase seems like the wrong approach.
This seems less like "We want to prevent memory errors." and more like "We hate C, we want Rust."
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.
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.
Ubuntu has not been famous for robustness as a distribution. It seems the tastes is a major factor as seen in this case.