alt Hacker NewsThis looks interesting and useful (I haven't tried it yet), but it is important to realize that every single useful Rust program has unsafe. Every single one. Why? Stdlib usage is full of it, and it must be by definition of what it does. In the same way you can't have a useful program without some side effects, so also you can't really have a useful program without doing some level of I/O and FFI, and I/O/FFI is always going to use unsafe under the covers.
That said, there is value in limiting your own unsafe use, and there might be value in limiting unsafe in the crates you use. However, this is really a question of "who do I trust to use unsafe? How much? Under what circumstances?" and NOT "is okay to have any unsafe?" because any useful program will contain a lot of unsafe if traced far enough in its call paths.
Penalizing the stdlib for using `unsafe` would be extremely counter-productive, because you could almost trivially remove all `unsafe` in the stdlib by moving those "unsafe" operations into codegen emitted by compiler (which is essentially how every other memory-safe language under the sun works, including Java, Python, etc.). Voila, no more unsafe in the stdlib... except now you have exactly the same code existing in a form that's both harder to inspect and doesn't benefit from the bevy of tools that exist to audit unsafe blocks in regular Rust code, meaning you have an implementation that's less safe in practice. And outside of the code contained in the stdlib, the majority of Rust crates don't use `unsafe` at all (exact proportion varying by domain; e.g. embedded use cases will probably all use `unsafe` somewhere).