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

I 100% agree that Rust doesn't guarantee an absence of leaks in any formal way. I dedicated a section to this fact: https://doc.rust-lang.org/nightly/adv-book/leaking.html

However I will say that Rust makes it a lot harder to accidentally leak resources (it's trivial adversarially -- but I don't consider that an interesting programming environment YMMV).

In e.g. Java you need to remember to `close` a File -- in Rust it will close itself as soon as you stop using it unless you do some wild things. We can't formally guarantee anything better than the Java scenario; it's equivalent to whoever you pass a file to having to call `close` on it.

However the defaults are reversed: In Java you don't close a File by default, and have to explicitly do something to close it. In Rust you close a File by default, and have to explicitly do something to not close it (mem::forget or Rc cycle).

This is a pretty general theme for the wins Rust provides: it picks the best default so simple things are simple, but gives you all the tools to bypass that default. By default you want to close files. By default you want to free memory. However you can leak these resources when it makes sense.

The most interesting case for me is our HashMap: we default to SipHash seeded with some OS entropy to prevent algorithmic complexity attacks. This is an explicit choice to protect our users against a relatively obscure problem. Honestly, it's probably not what most users of HashMap need. Determinism and speed is probably nicer. And yet the cost of not having that safety guard when you need it is pretty extreme.

However if you know what you're doing you can just grab a community crate with a different hasher and plug it into our HashMap. Easy as a single type annotation: https://github.com/shepmaster/twox-hash/blob/master/README.m...



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

Search: