Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> So I'm not sure how this can really improve the state of things compared to C with the equivalent bounds checks.

The simplest answer here is that a compiler-introduced bounds check is almost always better than a human one. Humans make bounds errors, compilers generally don't.

The longer answer is that the current state of the code does not guarantee its future state. The fact that bounds checks constitute the current majority of safety guardrails does not mean that future refactors won't benefit from Rust's temporal memory safety guarantees. Or more abstractly: it's easier to perform safe refactors when your safety properties compose natively, rather than having to bolt another layer of checks onto pre-existing language that doesn't support them natively.

Edit: Forgot to mention: another benefit of bounds checking in the language itself is optimization: when humans bounds-check, the compiler needs to recognize human patterns to safety remove or merge redundant bounds checks. When the language specifies its own bounds checks, the compiler knows exactly what they'll look like and can optimize accordingly. Modern optimizing compilers are very good at detecting human-written bounds, but a fully compiler-controlled optimization is going to beat a human-augmented optimization >95% of the time.



> Humans make bounds errors, compilers generally don't.

I think i saw this in a movie. It didn't turned well. /s




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: