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).
Is 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?
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.
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!
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.
Since 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.
