[abigailphoebe]

blaming the language is not the way to approach this. if an engineer writes bad code that’s the engineers fault, not the languages.

this was bad code that should have never hit production, it is not a rust language issue.

[echelon]

No. Don't say "you're holding it wrong". The language says "safe" on the tin. It advertises safety. This shouldn't be possible.

This is a null pointer. In Rust.

Unwrap needs to die. We should all fight to remove it.

[aw1621107]

> The language says "safe" on the tin. It advertises safety.

Rust advertises memory safety (and other closely related things, like no UB, data race safety, etc.). I don't think it's made any promises about hard guarantees of other kinds of safety.

[dafelst]

panics are safe, what are you talking about? It is nothing like a null pointer.

[abigailphoebe]

you either misunderstand the rust ethos or are intentionally misrepresenting it.

safe refers to memory safety.

once again, if you write bad code, that’s your fault, not the languages. this is a feature of rust that was used incorrectly.

[echelon]

Rust has grown beyond its original design as a "memory safe" language. People are using this as an HTTP/RPC server programming language now. WASM serverless jobs, etc. Rust has found itself deployed in a lot of unexpected places.

These folks are not choosing Rust for the memory safety guarantees. They're choosing Rust for being a fast language with a nice type system that produces "safe" code.

Rust is widely known for producing relatively defect-free code on account of its strong type system and ergonomics. Safety beyond memory safety.

Unwrap(), expect(), and their kin are a direct affront to this.

There are only two uses cases for these: (1) developer laziness, (2) the engineer spent time proving the method couldn't fail, but unfortunately they're not using language design features that allow this to be represented in the AST with static guarantees.

In both of these cases, the engineer should instead choose to (1) pass the Result<T,E> or Option<T> to the caller and let the caller decide what to do, (2) do the same, but change the type to be more appropriate to the caller, (3) handle it locally so the caller doesn't have to deal with it, (4) silently turn it into a success. That's it. That's idiomatic Rust.

This should be concerning to everyone:

https://github.com/search?q=unwrap%28%29+language%3ARust&typ...

I'm now panicked (hah) that some dependency of mine will unwrap something and panic at runtime. That's entirely invisible to users. It's extremely dangerous.

Today a billion people saw the result of this laziness. It won't be the last time. And hopefully it never happens in safety-critical applications like aircraft. But the language has no say in this because it isn't taking a stand against this unreasonably sharp edge yet. Hopefully it will. It's a (relatively) easy fix.

[abigailphoebe]

that's actually a very good point, fair enough, i agree.

regretfully i'm not sure if such a big language change can be made; though it would be nice.

here's to hoping!