Hacker News Reader

Comment by dbaupp | Hacker News Reader

What's a specific memory safety issue Rust has outside `unsafe` code?

The memory safety issues happen inside of “unsafe” code, thus it doesn’t eliminate memory safety issues.

I don't think this is a useful point, because by the same logic:

- Haskell doesn't eliminate memory safety issues, they happen when using unsafePerformIO (or Foreign.*Ptr, or inside the runtime, your choice),

- Python doesn't eliminate memory safety issues, they happen when using ctypes,

- JavaScript doesn't eliminate memory safety issues, they happen when calling into the C++ code of the browser,

- Java doesn't eliminate memory safety issues, they happen when using JNI.

All languages have some sort of escape hatch that can be used to drop to a lower level, in order to actually interface with the operating system (etc.), Rust is slightly unique in that it makes this escape hatch fairly explicit/prominent at the language level and also provides the power needed do that interfacing/implementation itself (additionally, one gets all the normal benefits of Rust inside `unsafe`, the feature just lets one do more, not change the semantics of existing code).

I never said i expect Rust to fix any of these problems, i would however expect it to at least try and introduce helpful constructs, instead of the ultimatum approach that every other language takes where you either program as expected or face the consequences.

It does provide a pile of helpful constructs (references, slices, generics, privacy), which, if they don't work 100%, are still brilliant building blocks for creating abstractions that expose safe interfaces, allowing the areas where "program as expected" is required to be concentrated into controlled areas/libraries. (And, all those features still work in the unsafe code, helping the programmer get it correct.)

It works really well in practice, even if it isn't bulletproof... there's nothing to stop a programmer typing 'unsafe' to side-step the safe interfaces in random places, but one quickly learns this is usually just heaping unnecessary debugger work on oneself, to track down little mistakes that the compiler would normally point to directly.

Some people say "half a hole is still a hole". To which I reply "but it's a much smaller hole".

Reply on news.ycombinator.com