Hacker News Reader

Comment by zuzun | Hacker News Reader

Memory safety is optional in Rust. It might not be obvious at the moment, because Rust is written by enthusiasts who enjoy fighting with the compiler until their code compiles, but once developers will be forced to use it on their jobs with tight deadlines, unsafe becomes the pass-the-borrow-checker cheat code.

View on HN

I write Rust at $WORK. Using `unsafe` to meet a deadline makes 0 sense. It doesn't disable the borrow checker unless you're literally casting references through raw pointers to strip lifetimes, which is... insane and would never pass a code review.

99% of the time if you're fighting the borrow checker and just want a quick solution, that solution is `clone` or `Arc<Mutex<T>>`, not `unsafe`. Those solutions will sacrifice performance, but not safety.

My girlfriend uses Rust for embedded systems at a large and important company. Everyone uses memory safety.

> Using `unsafe` to meet a deadline makes 0 sense... would never pass a code review.

I've seen unsound unchecked casts from &UnsafeCell or *mut to &mut in multiple codebases, including Firefox itself: https://github.com/emu-rs/snes-apu/blob/13c1752c0a9d43a32d05..., https://searchfox.org/mozilla-central/rev/7142c947c285e4fe4f....

Rust is used in production though at large companies: Amazon, Microsoft, Mozilla, etc... I would be highly surprised that the borrowchecker would be the reason code couldn't ship in the first place, once you get over the initial mental hurdles it's usually a non-issue.

Besides equivocating between a pervasively unsafe-by-default language and one with an explicit bounded opt-in is a little disingenuous. Time after time, it has been shown that even expert C developers cannot write memory safe C consistently, each line of code is a chance to blow up your entire app's security.

Unsafe does not turn off the borrow checker

https://steveklabnik.com/writing/you-can-t-turn-off-the-borr...

I was under the impression that even in rust unsafe blocks, you still had massive safety advantages over C and it isn’t just instant Wild West.

I’d love to red team the program that thinks Rust unsafe is easier to get right than tight ANSI C.

Why compare 'non-tight' Rust against 'tight' C?

Surely we should compare tight Rust (with some 'tight' unsafe sections) against tight C?

I must be more tired than I thought if I said “non-tight Rust” and forgot ten minutes later.

I just think if mistakes need to be literally low as possible you’ve got a better bet than Rust unsafe.

The language spec is smaller, the static analyzers have been getting tuned for decades, and the project leaders arent kinda hostile to people using it in the first place.

I think it's easier to write correct safe Rust than C, I wouldn't say it's easier to write correct Rust with unsafe blocks than C (many operations strip provenance, you can't free a &UnsafeCell<T> created from a Box<T>, you can't mix &mut and const but you might be able to mix Vec<T> and const (https://github.com/rust-lang/unsafe-code-guidelines/issues/2...), self-referential &mut or Pin<&mut> is likely unsound but undetermined), and it's absolutely more difficult to write sound unsafe Rust than C (sound unsafe Rust must make it impossible for callers to induce UB through any possible set of safe operations including interior mutability, logically inconsistent inputs, and panics).

What is "tight ANSI C"?

We could set up a prediction market for this. A study would be performed of attempts ti pentest randomly selected unsafe Rust and tight ANSI C programs. A prediction market used to estimate the probability of either language winning before publication of results. Someone needs to make this a thing.

I think unsafe rust is a lot more awkward to work with and easier to cause UB with compared to c and especially c++. This is just my opinion though!

&mut aliasing is a good example of running into instant UB in unsafe rust, but there are many more that you have to be aware of.

I would check out the unsafe rust "book" for yourself and see what you think. There is a section where you implement Vec and some other data structures from scratch!

https://doc.rust-lang.org/nomicon/intro.html

Unsafe code is rarely necessary, especially unsafe code that isn't just calling out to some component in C. You can easily forbid developers from pushing any code containing `unsafe` and use CI to automatically enforce it.

This is kinda disingenuous. Whenever we people use unsafe its like an alarm because you can setup CI system that warns DevOps team regarding the usage of unsafe code.

And, most of the time unsafe code is not required. I think many people will just use clone too much, or Arc rather than unsafe. Additionally, I have never seen unsafe code at least where I work.

Reply on news.ycombinator.com