Hacker News Reader

Comment by unwrap_abuse | Hacker News Reader

So the problem with rust you will find is the abuse of unwrap in ecosystem, so your code will need to be panic-safe.

We wanted to get rid of C++ exceptions but traded it for panic hell.

An important distinction is that rust doesn’t use exceptions for recoverable errors. You don’t have try/catch like you do in C++. Instead you use the Result type to propagate errors. This has the advantage of avoiding many of the downsides of exceptions (like leaving your program in a bad state) while making error handling more explicit.

This doesn't mean you don't still have to be panic-safe, though. This is mainly important for unsafe code, because it has to preserve memory safety even in the presence of panics. But it can also be important for safe code in an application that recovers from panics.

You are correct that there are circumstances where you have to consider panic safety. But those are rare. Most code is not unsafe, and catching panics is usually bad practice in Rust (though I am sure there are circumstances where it is needed). In C++ by contrast you have to think about panic safety almost everywhere. Rust’s error handling is a big improvement in that regard.

Rust programmers misuse unwrap and the like all the time, to the point that I’ve seen some projects explicitly state that they don’t do that, since nobody wants their library to crash their program because someone was too lazy to propagate errors.

Which brings me to the point: propagating errors is tedious enough that people are looking for shortcuts, which then cause other problems.

Somehow I must've been lucky enough to avoid this unwrap abuse in crates I use.

I think you maybe meant converting between errors in Rust can be tedious sometimes, but propagation is pretty easy.

The conversation is something that generally need's to happen rarely (like a few times per project?), but `thiserror` and `from` make this pretty ergonomic.

For other folks following along and possibly getting mislead by this (partial) nonsense, I'd encourage you to read a blog post I wrote about the topic of unwrap. I think it should clear up most things: https://blog.burntsushi.net/unwrap/

At a meta level, one of the reasons why there is so much focus on 'unwrap()' in particular is because it is often the precise point at which in your code where a runtime invariant is broken and thus leads to a panic. Nearly all code has runtime invariants in one form or another. The question is what happens when they're broken. In languages that are memory unsafe by default, the answer is often (but not always) "undefined behavior." In languages like Rust, or Python, or Go, the answer is often (but not always) "the process quits." The reality is more complicated than that, but those are a fine first approximation. For example, breaking a runtime invariant doesn't have to lead to undefined behavior or process termination. It can simply result in a logic error that leads to unexpected behavior.

Of course, making the issue more complicated is that sometimes 'unwrap()' is abused. And indeed, sometimes it is used in cases where an error ought to be returned. I find this to be generally pretty rare in popular libraries. But the key point here is that you can't just say, "oh I see unwrap() in a library, so now I'm going to scream ABUSE!!!!" It's more complicated than that.

How is it nonsense if you admit at the end (albeit after a straw-man of me allegedly screaming “abuse”) that it happens?

Result is being sold on HN as a great solution to error handling while there’s several crates available which are needed to polish its rough edges, rough edges which have led to e.g. unwrap abuse in the past.

It is tedious to shuffle around results, but this is never part of the sales pitch. And for those of us that don’t want to depend on all sorts of crates for the simplest things, that’s the reality.

Re your reply “Maybe improve your reading comprehension. I said "(partial) nonsense." Therefore, some of what you said wasn't nonsense. But some is. What a fucking revelation.”

Partial nonsense isn’t nonsense by definition, I believe, but I won’t dwell that point. I am surprised seeing a Rustacean being (mildly) offensive and even saying the f-word. I must say that I am proud of you, too many nowadays act like polite, pedantic robots. :-)

I didn't say "nonsense." I said "(partial) nonsense." If we use our powers of logical deduction, it therefore follows that I wasn't claiming that everything you said was nonsense. Hence the reason I added nuance to my comment, unlike yours. I'm trying to tease apart the convoluted mess you're making. You're aware of Brandolini's law, right? This is a microcosm of that. Some of what you're saying is bullshit, but not quite all of it, and aspects of it are rooted in truth and reasonable experiences. (For example, I also do not "depend on all sorts of crates for the simplest things.")

My tactic is to present nuance. You come back to me and instead of actually engaging with the nuance, starting whinging about what's being "sold on HN." Yawn.

> It is tedious to shuffle around results, but this is never part of the sales pitch.

This is a good example. Your sentence starts with something that I wouldn't agree with as a general rule, but I could certainly see it being true in specific circumstances. And even then, I'd want to explore those circumstances. That is, is it really a property of `Result` that makes it tedious, or is the problem of error handling in that context itself? It could be either.

But then you follow it up with whinging about "sales pitch." Are you talking about some kind of sales pitch put out by the Rust project? Because if so, please link it to me. Or are you talking about a bunch of random HN commentators that can be overzealous about just literally anything? I don't see anyone saying Result is the best thing since sliced bread. What I do see are people describing positive experiences with it, especially in relationship to alternative error handling paradigms. Is that really a sales pitch?

I mean, look at my top-level comment in this entire post. I sang the praise of sum types, and I did it by echoing what the OP said. Is that a sales pitch? Am I saying that sum types are the "best" at something? Am I saying that they have literally no costs at all? Am I saying that useful programs can't be written without sum types? Am I saying that all languages should be designed to include sum types?

No. No. No. No and no. Did some other people go a touch too bar and make broad pronouncements about "correct" language design? Oh yeah, absolutely. Are those people some kind of singular phenomenon unique to Rust? Fuck no. And it is absolutely fucking baffling that I need to explain that to someone who has been on HN for as long as you have. This observation is so banal that it's blub.

The Rust community always had a deep interest to sell Rust and did so through blog posts, comments and projects. I’ve seen this with many other languages on HN, but the zeal with which Rust is constantly shoved in the face of everyone is a tad more irritating than what I remember about what seemed to be grassroots interest in Ruby, Haskell or Objective-C.

When I read your top-level comment I don’t read a story from a random developer, I read an endorsement from a prominent member of the Rust community trying to paint Rust in a positive light, but conveniently omitting any negative aspects. This happens way too often to be a coincidence: the polite Rust developer educating others about the benefits of Rust may as well be a recurring character in this series.

Yet as companies actually start to use Rust and hit various problems, these are not given the same amount of attention. Obviously you don’t care about that, but this kind of submarine advertisement is a pet peeve of mine, so don’t be surprised if I continue to comment.

That is Grade-A-nonsense.

So what I'm getting from your comment is that it's not possible to say something positive about a project like Rust unless all commensurate trade offs are accounted for. Otherwise, the comment is a "submarine advertisement"? I didn't pipe into a conversation about non-Rust. The OP is about Rust. The OP mentioned sum types. I commented endorsing what OP said and to call extra attention to it, because sum types (with pattern matching and exhaustiveness checking) are amazingly useful. I also legitimately do not believe they have many downsides, if any at all. They might have downsides within the context of a particular language design (for example, Go, where their interaction with default values and interfaces would potentially be quite weird). But in general, no, sum types are pretty close to an unmitigated good thing in my view.

Does Rust writ large have downsides? Oh absolutely! So unless you're telling me I need to exhaustively enumerate every downside of Rust every time I mention something positive, then I don't know what you're getting on about.

> so don’t be surprised if I continue to comment.

That's not surprising? You've been posting low quality commentary in Rust threads for literal years. If there are people sick of the "advertising" for Rust, then there are also people who are sick of the people whinging about it. What would be surprising is if you started posting well informed productive comments in Rust topics.

What libraries have you found to use unwrap liberally?

_This_ is what I want to know.

The standard library is one example. Indexing into a vector unwraps, as do many other stdlib functions.

the docs[0] are clear:

> be careful: if you try to access an index which isn’t in the Vec, your software will panic!

> Use get() and get_mut() if you want to check whether the index is in the Vec.

In my experience, most people are using get() if the source of the index is untrusted

[0]: https://doc.rust-lang.org/std/vec/struct.Vec.html#indexing

A lot of these Rust complaints are just people not reading the docs (not trying to say Rust doesn't have legitimate usage friction; of course it does).

Pro tip: most popular crates have excellent documentation (I know it's a shocker coming from other languages). So, check stuff before you use it.

I assume this is because the ecosystem lowers the barrier to entry for writing an generating documentation (compared to other ecosystems).

I wasn’t complaining about anything. I was simply giving an example of a library that behaves in this way.

> Indexing into a vector unwraps

That's what it's supposed to do, RTFM.

Use .get() for safe access.

Er, yes I know, I use rust every day as a primary language. I was just giving an example, not claiming it wasn’t documented.

Then what is the issue if you know both the “fast-but-panicking” and “slow-but-Option-ing” versions?

First of all, neither is faster than the other.

Second, I never claimed it was an issue or a bad thing at any point. Someone asked for examples of libraries that panic, and I gave an example.

I must be missing something because it makes no sense to me that people seem to be responding defensively and claiming that I either don’t understand the Rust docs or am pointing out problems in Rust.

"Panic" and "exception" is literally the same thing.

Sorry you were misled, but programming is, indeed, hard, and no, you can't go shopping instead.

Panics and exceptions are not the same thing. For one, it's not possible to recover from a panic. You can handle a panic from within a handler before the program terminates, but you cannot resume execution as you can with exceptions.

You can recover from a panic though? I don't think you're required to call resume_unwind after catch_unwind. The underlying machinery is the same as C++ exceptions, so there's no reason that wouldn't work.

Obviously this is not something you're encouraged to do often, but there's applications where it might be reasonable.

A panic is an unrecoverable error caused by violating runtime invariants. A bug exists in the program and there is no (correct) way for the program to continue execution. For example, an array was accessed at index "-1".

Exceptions are a particular technique for dealing with errors in general, that can be used for both unrecoverable and recoverable errors. They infamously trade programmer convenience for hard to understand bugs, fragile run-time behavior and unmaintainable code.

A distinction without a difference, because "panics" and "exceptions" are literally the same code under the hood of the compiler and standard library.

Fragile run-time behavior and unmaintainable code is because programming is hard and cruft accumulates in the face of difficult requirements.

Renaming a thing that traumatized you in the past won't make the cause of the trauma go away.

Although the code generated might be similar, it's not a "distinction without a difference" because the language doesn't provide the same tools for interacting with panics as say C++ does with exceptions. There is no "try catch" for panics, you either catch them at the thread boundary or catch them with catch_unwind. Everything in the std lib is built with Result for errors that can be handled, not panic. Programming is hard, but that doesn't mean that certain language design choices don't have meaningful impact on what type of code becomes easier/harder to write. Other people are saying similar things, and I ask you listen to what they're saying, rather than talking about people being "traumatized" by a programming construct.

> you either catch them at the thread boundary or catch them with catch_unwind

So exactly like C++ exceptions then?

Reply on news.ycombinator.com