I’ve marked your words, but I think you have to eat them.

Studies by Microsoft and Google have already been done on this and Rust provides real tangible benefits. No one has ever claimed Rust eliminates all memory errors (if that’s the bar you’re setting), but it makes them vanishingly unlikely, even when you include the prescience of unsafe, thus “eliminating” memory errors (most, not all):

> Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop.

The old adage is important: do not left perfect be the enemy of good.

https://security.googleblog.com/2024/09/eliminating-memory-s...

The point of Rust, without counting `unsafe`, is to eliminate memory errors at compile-time. But the point of Rust, when including `unsafe`, is not to entirely eliminate memory errors at compile-time, but to make it feasible to cordon off the unsafe parts into realistically-auditable sections with documented safety invariants. At this it has been dramatically successful, almost beyond anyone's wildest hopes. I have worked on embedded, bare-metal Rust codebases (i.e. the codebases you would most expect to have to do grotty memory faffing) with fewer than 5% of files containing `unsafe` blocks, whereas high-level unsafe code usually has no `unsafe` blocks whatsoever. It's an incredible force multiplier for writing correct low-level code.

Handling of exceptions is not enforced at compile time, while ownership is.

Better example might be statically typed languages. They were harder to use at first, but now with good type inference and features like generics, they are much more ergonomic than at first. The accessibility gap between static and dynamic languages has narrowed with time and maybe we can expect that user-friendliness of ownership will also improve like that.

Rust already has.