I guarantee they'll be complaining about unsafe rust in 10-15 years, mark my words. Just like they said exceptions "force" a programmer to deal with all error cases (newsflash, they still ignore it), rust will not eliminate memory errors.
I guarantee they'll be complaining about unsafe rust in 10-15 years, mark my words. Just like they said exceptions "force" a programmer to deal with all error cases (newsflash, they still ignore it), rust will not eliminate memory errors.
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...
[flagged]
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.
> without counting `unsafe`,
Well, if you exclude all the bad code people have wrote, c is a safe language... See the point I'm making here?
If coders couldn't be trusted multiple times in the past, and we had to invent language level features to correct them, but they still continued to make either the same, or a new, mistakes.... Why is rust any different?
I guarantee you we will be complaining about unsafe rust in the future because rust doesnt really bring anything new to the table other than trivial cases that were easy to code in the first place. Rust brings you nothing a c coder couldn't already do in c.... They haven't solved the enduring problems of computer science, they have simply kicked the can down the road
Even if you think having better developers would prevent the problem, the average Rust developer is probably better at writing unsafe code than the average C developer.
> Well, if you exclude all the bad code people have wrote
Nobody is doing this. Please read my comment again.
The difference I see there is any line in a C codebase could have these issues, whereas in Rust they're specifically marked as unsafe sections, with the language having a clear list of invariants it expects the programmer to uphold in an unsafe block. Additionally Rust has a culture of developers specifically justifying the unsafe block and why it's correct in comments. It's a massive reduction of the scope of the code that needs audited, that doesn't mean there can't be mistakes in it, just that it's easier to verify certain properties of the whole codebase.
In general it helps if you read past the first six words of what someone says before responding.
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.