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%...
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.
> 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.
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.
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?
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.