undefined | Better HN

0 pointsechelon4mo ago0 comments

We shouldn't be using unwrap() or expect() at all.

This is Rust's Null Pointer Exception.

unwrap(), expect(), bad math, etc. - this is all caused by lazy Rust developers or Rust developers not utilizing the language's design features.

The language should grow the ability to mark this code as dangerous, and we should have static tools to exclude this code from our dependency tree.

I don't want some library I use to `unwrap()` and cause my application to crash because I didn't anticipate their stupid panic.

Rust developers have clearly leaned on this crutch far too often:

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

The Rust team needs to plug this leak.

0 comments

burntsushi4mo ago

I'm on the Rust libs-api team and you're mistaken. I use `unwrap()` all the time.

My blog on this topic was linked above, you should read it: https://burntsushi.net/unwrap/

underdeserver4mo ago

Eh, "mistaken" might be a bit harsh. He's stating an opinion, which you and I disagree with.

> The language should grow the ability to mark this code as dangerous, and we should have static tools to exclude this code from our dependency tree.

Might be useful to point out that this static tool exists (clippy::unwrap_used).

burntsushi4mo ago

They said:

> unwrap(), expect(), bad math, etc. - this is all caused by lazy Rust developers or Rust developers not utilizing the language's design features.

That's factually incorrect. (And insulting.)

1 more reply

petcat4mo ago

How would they plug it? Just deprecate .unwrap and .expect and then remove them from the API completely?

j / k navigate · click thread line to collapse

0 pointsechelon4mo ago0 comments

We shouldn't be using unwrap() or expect() at all.

This is Rust's Null Pointer Exception.

unwrap(), expect(), bad math, etc. - this is all caused by lazy Rust developers or Rust developers not utilizing the language's design features.

The language should grow the ability to mark this code as dangerous, and we should have static tools to exclude this code from our dependency tree.

I don't want some library I use to `unwrap()` and cause my application to crash because I didn't anticipate their stupid panic.

Rust developers have clearly leaned on this crutch far too often:

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

The Rust team needs to plug this leak.

0 comments

burntsushi4mo ago

I'm on the Rust libs-api team and you're mistaken. I use `unwrap()` all the time.

My blog on this topic was linked above, you should read it: https://burntsushi.net/unwrap/

underdeserver4mo ago

Eh, "mistaken" might be a bit harsh. He's stating an opinion, which you and I disagree with.

> The language should grow the ability to mark this code as dangerous, and we should have static tools to exclude this code from our dependency tree.

Might be useful to point out that this static tool exists (clippy::unwrap_used).

burntsushi4mo ago

They said:

> unwrap(), expect(), bad math, etc. - this is all caused by lazy Rust developers or Rust developers not utilizing the language's design features.

That's factually incorrect. (And insulting.)

1 more reply

petcat4mo ago

How would they plug it? Just deprecate .unwrap and .expect and then remove them from the API completely?

j / k navigate · click thread line to collapse