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.

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.

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.

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 [email protected] and we believe you'll post only civilly and substantively in the future.

This kind of resource DoS attack doesn't seem like it's directly related to safe/unsafe. I think you would be just as likely to forget to put a resource limit if you were writing in Haskell.

> so appealing and easy to jump into unsafe territory.

I've almost never seen unnecessary unsafe code being used in Rust. I've seen it very few times for performance, but it's carefully done.