4 ms·

Yes, I always thought it was wrong to use unwrap in examples. I know, people want to keep examples simple, but it trains developers to use unwrap() as they see

• inferiorhuman 11mo ago
  Dunno, I think the alternatives have their own pretty significant downsides. All would require front loading more in-depth understanding of error handling and some would just be quite a bit more verbose. IMO making unwrap a clippy lint (or perhaps a warning) would be a decent start. Or maybe renaming unwrap.
  • jandrewrogers 11mo ago
    This strikes me as a culture issue more than one of language. A tenet of systems code is that every possible error must be handled explicitly and exhaustively close to the point of occurrence. It doesn’t matter if it is Rust, C, etc. Knowing how to write systems code is unrelated to knowing a systems language. Rust is a systems language but most people coming into Rust have no systems code experience and are “holding it wrong”. It has been a recurring theme I’ve seen with Rust development in a systems context. C is pretty broken as a language but one of the things going for it is that it has a strong systems code culture surrounding it that remembers e.g. why we do all of this extra error handling work. Rust really needs systems code practice to be more strongly visible in the culture around the language.
    • empath75 11mo ago
      Unwrap _is_ explicitly handling an error at the point of occurrence. You have explicitly decided to panic, which is sometimes a valid choice. I use it (on startup only) when server configs are missing or invalid or in CLI tools when the options aren't valid. Crashing a pod on startup before it goes Ready is a valid pattern in k8s and generally won't cause an outage because the previous pod will continue working.
    • inferiorhuman 11mo ago
      A tenet of systems code is that every possible error must be handled explicitly and exhaustively close to the point of occurrence. All the more reason it doesn't really belong in examples for third party libraries.
• frumplestlatz 11mo ago
  I have to disagree that unwrap is ever OK. If you have to use unwrap, your types do not match your problem. Fix them. You have encoded invariants in your types that do not match reality. Change your API boundary, surface the discrepancy between your requirements and the potential failing case at the edges where it can be handled. If you need the value, you need to handle the case that it’s not available explicitly. You need to define your error path(s) Anything else leads to, well, this.
  • echelon 11mo ago
    This. This is a failure caused by lazy Rust programming and not relying on the language's design features. It's a shame this code can even be written. It is surprising and escapes the expected safety of the language. I'm terrified of some dependency using unwrap() or expect() and crashing for something entirely outside of my control. We should have an opt-in strict Cargo.toml declaration that forbids compilation of any crate that uses entirely preventable panics. The only panics I'll accept are those relating to memory allocation. This is one of the sharpest edges in the language, and it needs to be smoothed away.
  • quotemstr 11mo ago
    > If you have to use unwrap, your types do not match your problem The problem starts with Rust stdlib. It panics on allocation failure. You expect Rust programmers to look at stdlib and not imitate it? Sure, you can try to taboo unwrap(), but 1) it won't work, and 2) it'll contort program design in places where failure really is a logic bug, not a runtime failure, and for which unwrap() is actually appropriate. The real solution is to go back in time, bonk the Rust designers over the head with a cluebat, and have them ship a language that makes error propagation the default and syntactically marks infallible cleanup paths --- like C++ with noexcept.
    • empath75 11mo ago
      We flag unwrap/expect usage in lints and have limited it to just server startup where we want the server to crash if a file is missing...
    • 11mo ago
• wongarsu 11mo ago
  > 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 11mo 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 11mo ago
      How would they plug it? Just deprecate .unwrap and .expect and then remove them from the API completely?
    • burntsushi 11mo 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 11mo 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).
• gwd 11mo ago
  > Yes, I always thought it was wrong to use unwrap in examples. And because it gets picked up by LLMs. It would be interesting to know if this particular .unwrap() was written by a human.
  • mattacular 11mo ago
    There is a prevailing mentality that LLMs make it easy to become productive in new languages, if you are already proficient in one. That's perhaps true until you suddenly bump up against the need to go beyond your superficial understanding of the new language and its idiosyncrasies. These little collisions with reality occur until one of them sparks an issue of this magnitude. In theory, experienced human code reviewers can course correct newer LLM-guided devs work before it blows up. In practice, reviewers are already stretched thin and submitters absolute to now rapidly generate more and more code to review makes that exhaustion effect way worse. It becomes less likely they spot something small but obvious amongst the haystack of LLM generated code bailing there way.
    • gwd 11mo ago
      > There is a prevailing mentality that LLMs make it easy to become productive in new languages, if you are already proficient in one. Yes, and: I've found this to be mostly true, if you make sure you take the time to deeply understand what the code is doing. When I asked an LLM to do something for me in Javascript, then I said, "What if X happens, wouldn't that cause Y? Would it be better to restructure it like so and so to make it more robust?" The LLM immediately improves it. Any experienced programmer who was taking the time to review this code, on learning that unwrap() has a "panic" inside, would certainly change it. But as you say, reviewers are already stretched thin.
  • empath75 11mo ago
    I have removed many 'unwraps' from copilot and cursor generated code, but cursor is a lot better at it than copilot was.