Hacker News Reader

Comment by foldr | Hacker News Reader

It's worth bearing in mind that some of these runtime panics would have happened anyway even if the code had been implemented in (e.g.) Rust. Ugly real world code tends to make quite frequent use of unwrap() or equivalents. For example: https://github.com/search?q=repo%3Arust-lang%2Frust+.unwrap%...

View on HN

Rust is a lot better in this aspect, but this is a symptom of not having proper code review and standards. Do not forget that in some scenarios using unwrap is totally fine if a panic is acceptable. The same could be said for javascript: How many time have we not wrapped JSON.parse inside a try catch? More than we would like to admit. Really appreciate Rust “forces” you to handles all execution paths.

My link is to the rust repo on github. Does the Rust project not have proper standards for Rust code?

> Do not forget that in some scenarios using unwrap is totally fine if a panic is acceptable.

Looking through the first few pages, most of these panics are easy to audit, and are infallible or in contexts where it doesn't matter (internal tooling, etc). That's a pretty stark difference to every single reference being a potential landmine.

Yes, you are probably less likely to get a panic caused by a nil reference in Rust than in Go. My point is that the equivalent software written in Rust (or most other languages with option types) would probably have had at least some of these very same bugs.

It's also worth reading the examples you post

Like, one of the first files has only .unwraps in the comments (like a dozen of them in a file), some are infallible uses, some are irrelevant-to-runtime tooling, etc.

But anyway, "some" is a lot smaller than "all". Just like some of memory safety issues would also have happened since you can still use unsafe in Rust, yet it's still a big step forward in reducing those issues in the ugly real world

It's a list of all instances of ".unwrap()" in the project, so of course it includes instances irrelevant to my point. Seems uncharitable to assume that I haven't looked through it on that basis.

Then please pinpoint some problematic ones, so that not every reader has to delve into pages to continue the discussion.

The point is precisely that it's not always easy to figure out which instances are problematic.

If you think about it a bit, given that bugs are relatively rare in a mature project, it's going to be difficult to find a use of unwrap that's definitely bad.

My basis is the %, not the simple fact that it has irrelevant instances.

So let me charitably ask directly: have you looked through all the examples at least on the first couple of pages? And if you have, what % of instances is relevant to your point?

I think this is covered in my reply to shakow. Unless Rust is absolutely riddled with bugs, it’s obviously going to be hard to find uses of unwrap that are definitely bad. The point is that there’s no way to easily assure yourself that all the uses of unwrap are definitely good.

It would be similarly difficult to trawl through the source of the Go compiler and find definitely bad instances of pointer dereferencing. So does that mean that it’s not actually a problem in Go either?

You can `grep unwrap` for Rust, you need an entire SAT solver for Go.

What do you think the borrow checker is?

A completely unrelated construct?

That's almost literally what I just did, but what use is it? No-one is really going to go through all those unwrap calls and check them.

But... they could. And also, they do? It's not uncommon.

All of those could be checked or irrelevant, I have no idea.

Reply on news.ycombinator.com