Hacker News Reader

Comment by danarmak | Hacker News Reader

Easy is not the same as necessary. At least high-security projects like OpenSSL could enforce a policy of not using unsafe code, and it's easy to validate that there's no unsafe code or that the few known instances are very well vetted.

View on HN

You could do the same with C code -- it is getting everyone to follow the policies that is the hard part. Even compiling Rust code in release mode instead of debug removes some essential safety features. Should be clear by now that "policies" just doesn't work, but no, project are repeating the exact same mistake over and over again. :)

The crucial difference is between a policy, which people can not follow (and you might not catch them), and a language or compiler restriction, which people can't work around without doing something drastic like shelling out to a new process, which you can catch (in a well built language).

What essential safety features are removed? The only thing I can think of this referring to is assertions, and we do the opposite: assert stays in all builds, debug_assert is only in debug builds.

Integer overflow checking, for example.

Integer overflow cannot result in memory safety violations in Rust.

But it can overflow, which will result in a different value that the programmer might expect, which can give an attacker a nice "information leak" or worse. This could be a security bug!

Exactly. Memory safety is a very nice property, but is not complete by itself. This primary emphasis on memory safety was part of a critique of Rust by Andrei Alexandrescu: https://www.quora.com/Which-language-has-the-brightest-futur....

And even wrt memory, Rust (with the standard library) is not free of its own warts, see the OOM situation. See e.g https://news.ycombinator.com/item?id=10545877 for a discussion on this.

Just to be clear: I generally like the ideas of Rust. I just dislike its presentation by some as a magic solution to all kinds of concerns.

Reply on news.ycombinator.com