Hacker News Reader

Comment by simias | Hacker News Reader

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.

View on HN

I believe Rust isn't exactly memory safe either: 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.

What 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.

Oops, 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.

That looks like memory safety to me - deliberate panic instead of returning what is next to `vec[2]` in memory.

Reply on news.ycombinator.com