Hacker News Reader

Comment by diarrhea | Hacker News Reader

> This is a non sequitur. Both Rust and Zig and any other language has the ability to end in an exception state.

There are degrees to this though. A panic + unwind in Rust is clean and _safe_, thus preferable to segfaults.

Java and Go are another similar example. Only in the latter can races on multi-word data structures lead to "arbitrary memory corruption" [1]. Even in those GC languages there's degrees to memory safety.

1: https://go.dev/ref/mem

View on HN

I'll take a small panic and unwind any day over a total burnout crash. Matters in code and life.

> A panic + unwind in Rust is clean and _safe_, thus preferable to segfaults

Curious about safety here: Are kernel / cross-thread resources (ex: a mutex/futex/fd) released on unwind (assuming the stack being unwound acquired those)?

Good question. For fds their Drop implementation closes them, yes. Rust Mutexes will be poisoned on panic (not unlocked). Not sure about futexes.

But if Rust panic’s, the entire process is dead, so everything gets reclaimed on exit by the kernel. Total annihilation.

All modern OS’s behave this way. When your process starts and is assigned an address, you get an area. It can balloon but it starts somewhere. When the process ends, that area is reclaimed.

The OS is my GC. It's why I segfault liberally.

I see your point. At some level serverless is popular for this reason. You can just forget about memory leaks (like Vercel does with NextJS ;)

That said, the OS can be a lousy GC; for instance, POSIX-compliant Kernels may not clean up shm regions after processes.

Reply on news.ycombinator.com