3 ms·
The "why" is memory safety without GC, which as far as I know no other non-toy language provides. It's also why I feel that the comparison with Zig is a bit un
by simias 6y ago
The "why" is memory safety without GC, which as far as I know no other non-toy language provides.
It's also why I feel that the comparison with Zig is a bit unfair: Zig is not memory safe. If Rust was willing to compromise with this constraint it would remove could remove some of the intellectual overhead for the developer and result in simpler looking, if unsafe, code.
But then it would also destroy the one killer feature of the language.
- loup-vaillant 6y agoI believe Rust isn't exactly memory safe either: https://stackoverflow.com/questions/24898579/why-does-the-rust-compiler-allow-index-out-of-bounds https://stackoverflow.com/questions/24898579/why-does-the-ru... (and I think bounds checking can be turned off). The borrow checker is a Big Deal™, but even outside unsafe blocks, Rust did not go all the way to perfect safety. Safety remains a spectrum, not a binary choice. The extreme end of that spectrum isn't Rust. It's using a proof assistant to mechanically check the correctness of your entire program.
- OvermindDL1 6y agoWhat are you referencing on that page that is memory and safe, the program panicking when attempting to access invalid memory is one of the safety features, it means you have a programming error that you need to correct and it is bailing right now to prevent anything bad from happening.
- loup-vaillant 6y agoOops, after a cursory search, it would seem there's no easy way to disable runtime bounds checking. While runtime crashes aren't ideal, I do stand corrected, sorry. Still, I think my point about safety being a cursor instead of a switch remains.
- bogeholm 6y agoThat looks like memory safety to me - deliberate panic instead of returning what is next to `vec[2]` in memory.