The article has nuance. It's good.
But the language has made it too easy to unwrap/expect and panic.
This escape hatch should exist, for sure. But it ought to be more explicit, and more of a pain.
It is far too easy to reach for this tool.
But the language has made it too easy to unwrap/expect and panic.
This escape hatch should exist, for sure. But it ought to be more explicit, and more of a pain.
It is far too easy to reach for this tool.
I ask because I suspect you've got a bit of motte and bailey going on here. The motte is "hey let's make unwrap/expect more verbose because we want people to be REALLY sure," but the bailey is "let's actually make everything that can panic a lot more verbose and totally change the character of the language and make it a lot less practical."
I'd encourage you to read the "lint" section near the end: https://blog.burntsushi.net/unwrap/#should-we-lint-against-u...
It absolutely is. Modern language design should be discouraging getting an element by index; there are usually better alternatives e.g. iterating through a datastructure, or using combinators like zip to build the datastructure/view you need.
Indexing may incur range checks, but iterators/combinators are pretty much destined to have them elided.
Why not try and be a bit more kind?
I'll be sure to let my artificial users know that.
Like, my god man, next time just come out and say, "I do not consider your work or the use cases you care about valid, and thus I am going to dismiss everything you say on that basis." At least be honest.
There's a lot more stuff out there besides grep tools that need to go as fast as possible. I'm glad Rust exists for that and I'm glad its design is full of practical trade offs that people like you don't seem to see as reasonable.
"Artificial microbenchmarks" are very useful if there's a good chance the code might be called a few thousand times in a loop. If you write generic code that may get used by thousands or even millions of applications then these small differences do matter, and add up.
Also I think a lot of code will be needless awkward too; sometimes I really just want to get the first or second or last index. I don't want or need to iterate: I just want exactly nth entry, nothing more, nothing less. Yes, you need to be careful with it, but entirely removing them is not much of a solution.
IMHO there's a qualitative difference in the programmer's expectations when indexing a slice vs calling a function which has been explicitly written to return an error condition. Years of convention causes us to expect indexing errors and to write defensively. But the implied contract of a Rust function with a Result is that the user should do probably do something with the result other than panic in most cases.
I agree that panicing is a legit option. And I agree with the scenarios laid out in the article. And I also don't think lint is the right way to handle it.
But I'm currently in a codebase that is full of unwraps all over -- which the developers did for expediency "get this thing shipped" reasons -- and that (and other codebases I've seen) is what leads me to the conclusion that the ergonomics of putting unwrap right out there in our faces aren't ideal.
Hell, even calling it "result_or_panic" would have perhaps made casual users of it pause and think about what they were doing. There are likely syntactical tools that could have been put in place to really make the user think before creating a panic.
(FWIW safety isn't my primary reason for preferring Rust. I'd be fine with "C++ with a ML-style type system." The general tamping down of footguns is great, though)
Anyway, I'm sympathetic to the plight of finding yourself in a codebase full of bugs. But I think 'unwrap()' gets a bad rap here. It just so happens that it makes those bugs easily visible and it happens to be a common manifestation of it.
Personally, I don't think a different name for 'unwrap()' would have helped things. One common suggestion is 'or_panic()'. If we could go back and do it all over again, I think 'or_panic()' would be worth a shot. But I think that ship has sailed.
But like I said, fair enough.