3 ms·
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
by danarmak 10y ago
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.
- bjourne 10y agoYou 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. :)
- danarmak 10y agoThe 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).
- rustywut 10y agoBut Rust is ugly and C is beautiful. Why would someone want to work in an ugly language all day?
- danarmak 10y agoIs the beauty you see in C inseparable from its unsafety? Are the unsafe parts that other languages don't have the most beautiful ones? There's a big difference between arguing for safety and arguing for Rust specifically. Everyone likes some languages and dislikes others. Can you design a safe(r) language that you would consider to be beautiful?
- rustywut 10y agoYour points seem valid, I don't know why you're getting downvoted. Butt hurt Rust lovers I guess?
- sctb 10y agoSince this account seems to have been created solely to violate the guidelines with, we've banned it. We're happy to unban accounts if you email hn@ycombinator.com and we believe you'll post only civilly and substantively in the future.
- steveklabnik 10y agoWhat 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.
- bjourne 10y agoInteger overflow checking, for example.
- wbl 10y agoInteger overflow cannot result in memory safety violations in Rust.
- ben_bai 10y agoBut 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!
- gajjanag 10y agoExactly. 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-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why 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 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.