The problem(s) with unwrap

[quinedot]

@JeffG

It just doesn't LOOK like other languages. It gets all tangled up here. It does.

You gotta keep in mind that many people in tech are switching learning many different things.

As a fluent Rust user, I don't want implicitly nullable types -- or a "mode" that acts like Rust has them. That's not simplifying the language; that's making things more complex; now your have to know the "mode" to have a clue what's going on. (I could see something like an IDE mode, though I'd never use it.)

When I program in other languages, they don't bend over backwards to provide a mode pretending that they have sum types (which I consider an improvement). Instead I have to deal with nulls/undefined/magic values. Such are the trials of being a polyglot; there is no universal intersection of languages. Much less one that's the most intuitive to every programmer.

@JeffG

there's lots of tutorials with unwrap and people see it and say "that's not readable code" (then go to another language).

@JeffG

The language is WAY TOO VERBOSE. Compare with python - night and day. having an implicit mode where things like ? weren't even needed, would be better imho

Questions of uptake and industry acceptance may have been a significant point 5-8 years ago, but I think those days have passed. Rust isn't going anywhere. unwrap hasn't prevented its growth. There's no need to emulate some (very different!) language for survival.

It's not the solution to everything, not everybody has to like it, and that's fine.

[jjpe]

@JeffG

It just doesn't LOOK like other languages. It gets all tangled up here

This is fine: It has never been, nor is it now, a goal of Rust to look like other languages.

@JeffG

You gotta keep in mind that many people in tech are switching learning many different things.

I think this is a virtue rather than a vice: making a language clearly recognizable in terms of its syntactic atoms helps rather than hinders remembering the differences in semantics between languages.

The worst you might be able to say about it is that you're not used to it, and if so, that's ok. But one opinion does not consensus make, I'm afraid.

@JeffG

The language is WAY TOO VERBOSE.

It can be verbose relative to some other languages, yes. But Rust is a systems language, so comparing to a scripting/glue language like Python is a bit disingenuous, as the use cases for the languages, and thus their design, are very different.

A better point of comparison would be another systems language like C++, and in such a comparison Rust doesn't fare all that poorly.

Finally, I agree with @quinedot that extra "modes" would be adding rather than removing complexity. Worse, this is true in multiple domains: in the compiler implementation (i.e. it makes maintaining the compiler and growing new features more difficult) but also for each and every Rust user out there, in the form of added mandatory context to remember.

[jerusdp]

@JeffG

• It's just code clutter and hurts readability - could have post parenthesis marker like u, such as get_data()u; and that u represents that the compiler needs to add .unwrap() there, but it should be different for option and result so maybe s for some and r for result - something like that.
• You don't know if the call to unwrap is for an option or result - should be separated! Very poor readability.

I don't disagree with either point here. But perhaps, in a way that if the very point of unwrap. It is a short cut to properly handling to possible conditions where you are assuming that the case will always be good. If you think it ugly then it always forces you to think if you should really be using a more elegant solution

• Use the ? and admit that your function is fallible by implementing result
• Use a local match forcing the creation of code to manage both cases (if you are generating an empty err or none unwrap suddenly seems elegant)
• Recognise that the function will not fail in this case and the code can be safely unwrapped (perhaps a comment is in order to explain).

In practice I find that unwrap is only rarely used in production code and more often in the controlled environment of testing where the inputs are certain the expected output known (and indeed the result of a failed unwrap desired)

[JeffG]

Well, I'd be defending every side of it if I GOT PAID too... I'm telling you what it looks to people deciding whether or not they want to Rust - and it's a big NOT for most...

[jjpe]

The Rust ecosystem is growing at quite a remarkable pace. It's been adopted by multiple huge conglomerates (e.g. Microsoft, Amazon, Google) and crates for just about every possible use case are popping up, even in domains where Rust historically hasn't had a large presence e.g. machine learning. It also consistently ranks among the most beloved languages by programmer surveys eg StackOverflow. In addition, at the very least 1 national government has basically given it its seal of approval (that'd be Uncle Sam) in terms of the language providing a secure base to build digital infrastructure on.

So with all that, I'd like to ask where you get the impression that "it's a big NOT for most"?

[steffahn]

Unfortunately, the discussion in this thread has stopped being productive. As it was explicitly also just a “rant”, it seems partially off-topic for the internals forum, anyway; so I don’t think we need to keep it listed, either.