4 ms·

> at least do `expect("damn it, how did this happen")` That gives you the same behavior as unwrap with a less useful error message though. In theory you can wr

> at least do `expect("damn it, how did this happen")` That gives you the same behavior as unwrap with a less useful error message though. In theory you can write useful messages, but in practice (and your example) expect is rarely better than unwrap in modern rust

echelon 1y ago
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&type=code https://github.com/search?q=unwrap%28%29+language%3ARust&typ... The Rust team needs to plug this leak.
- petcat 1y ago
  How would they plug it? Just deprecate .unwrap and .expect and then remove them from the API completely?
- burntsushi 1y 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/ https://burntsushi.net/unwrap/
  - underdeserver 1y 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).
    - burntsushi 1y 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.)
      - underdeserver 1y ago
        I disagree with that characterization. Using unwrap() like you suggest in your blog post is an intentional, well-thought-out choice. Using unwrap() the way Cloudflare did it is, with hindsight, a bad choice, that doesn't utilize the language's design features. Note that they're not criticizing the language. I read "Rust developers" in this context as developers using Rust, not those who develop the language and ecosystem. (In particular they were not criticizing you.) I think it's reasonable to question the use of unwrap() in this context. Taking a cue from your blog post^ under runtime invariant violations, I don't think this use matches any of your cases. They assumed the size of a config file is small, it wasn't, so the internet crashed. ^ https://burntsushi.net/unwrap/#what-is-my-position https://burntsushi.net/unwrap/#what-is-my-position
        burntsushi 1y ago
        The commenter also said: > We shouldn't be using unwrap() or expect() at all. So the context of their comment is not some specific nuanced example. They made a blanket statement. > Note that they're not criticizing the language. I read "Rust developers" in this context as developers using Rust, not those who develop the language and ecosystem. I have the same interpretation. > I think it's reasonable to question the use of unwrap() in this context. Taking a cue from your blog post^ under runtime invariant violations, I don't think this use matches any of your cases. They assumed the size of a config file is small, it wasn't, so the internet crashed. Yes? I didn't say it wasn't reasonable to question the use of unwrap() here. I don't think we really have enough information to know whether it was inappropriate or not. unwrap() is all about nuance. I hope my blog post conveyed that. Because unwrap() is a manifestation of an assertion on a runtime invariant. A runtime invariant can be arbitrarily complicated. So saying things like, "we shouldn't be using unwrap() or expect() at all" is an extreme position to carve out that is also way too generalized. I stand by what I said. They are factually mistaken in their characterization of the use of unwrap()/expect() in general.

echelon 1y ago

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&type=code https://github.com/search?q=unwrap%28%29+language%3ARust&typ... The Rust team needs to plug this leak.

petcat 1y ago
How would they plug it? Just deprecate .unwrap and .expect and then remove them from the API completely?
burntsushi 1y 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/ https://burntsushi.net/unwrap/
- underdeserver 1y 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).
  - burntsushi 1y 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.)
    - underdeserver 1y ago
      I disagree with that characterization. Using unwrap() like you suggest in your blog post is an intentional, well-thought-out choice. Using unwrap() the way Cloudflare did it is, with hindsight, a bad choice, that doesn't utilize the language's design features. Note that they're not criticizing the language. I read "Rust developers" in this context as developers using Rust, not those who develop the language and ecosystem. (In particular they were not criticizing you.) I think it's reasonable to question the use of unwrap() in this context. Taking a cue from your blog post^ under runtime invariant violations, I don't think this use matches any of your cases. They assumed the size of a config file is small, it wasn't, so the internet crashed. ^ https://burntsushi.net/unwrap/#what-is-my-position https://burntsushi.net/unwrap/#what-is-my-position
      - burntsushi 1y ago
        The commenter also said: > We shouldn't be using unwrap() or expect() at all. So the context of their comment is not some specific nuanced example. They made a blanket statement. > Note that they're not criticizing the language. I read "Rust developers" in this context as developers using Rust, not those who develop the language and ecosystem. I have the same interpretation. > I think it's reasonable to question the use of unwrap() in this context. Taking a cue from your blog post^ under runtime invariant violations, I don't think this use matches any of your cases. They assumed the size of a config file is small, it wasn't, so the internet crashed. Yes? I didn't say it wasn't reasonable to question the use of unwrap() here. I don't think we really have enough information to know whether it was inappropriate or not. unwrap() is all about nuance. I hope my blog post conveyed that. Because unwrap() is a manifestation of an assertion on a runtime invariant. A runtime invariant can be arbitrarily complicated. So saying things like, "we shouldn't be using unwrap() or expect() at all" is an extreme position to carve out that is also way too generalized. I stand by what I said. They are factually mistaken in their characterization of the use of unwrap()/expect() in general.