Hacker News Reader

Comment by vlovich123 | Hacker News Reader

> So far I've always succeeded without using "unsafe" or indices, but it drags down productivity.

I really don’t understand this perspective. The whole philosophy of Rust is one where you document why “unsafe” is safe. It is not and never has been a goal to make everything safe because that is an impossible goal to merge with high performance systems language because hardware itself is unsafe. It’s why the unsafe keyword exists. If that wasn’t the goal, unsafe wouldn’t.

View on HN

If unsafe is not used, then no one has to determine whether the unsafe parts are actually safe.

Sure, but taken to an extreme you see the absurd degree you have to contort yourself. And that’s to the current version of the proof checker - some unsafe’s are even only temporary until a better prover comes by.

You shouldn’t go out of your way to use unsafe, but between that and 2 weeks refactoring, I’ll take the unsafe and use tools like miri or ASAN to provide extra guards. Engineering is inherently about making practical choices.

I just start everything with

    #![forbid(unsafe_code)]

It can be preferable to avoid unsafe when reasonable to do so. Programmers are merely human and will make a mistake at some point, and by avoiding unsafe you at least get the guarantee that the buggy behaviour is sound and (aside from race conditions) more predictable.

I think you misunderstand me. I’m not saying that unsafe should be the first thing you reach for. But if you can’t find an easy way to express it safely, and the only path visible is a time costly refactor, it can still be the most cost effective approach and shouldn’t be ignored.

Even ignoring the practicality approach, there’s a reason you see it in things like crossbeam or zerocopy - not everything worthwhile expressing can even be expressed in purely safe code wether because of performance or purely because the ownership lifetime cannot be understood due to the limitations of the borrow checker even when it is indeed safe code.

This is exactly how technical debt accumulates. You can write a comment documenting that "unsafe is actually safe here in routine X because Y will always do Z," but if the code lives long enough, someone may eventually change X or Y in a way that falsifies that claim, or try to cut-and-paste X's code into a new context without those guarantees. No, that's not /prudent/, but it happens nevertheless, and the costs of tracking down and fixing the errors are almost always higher than just implementing more conservatively in the first place.

Reply on news.ycombinator.com