DEV Community

Two Rust features that I miss in Other languages

YJDoc2 on April 13, 2023

Hello everyone! Now-a-days I am writing code in several different languages : Rust, C , JavaScript, Python. While all of these have their own use ...

Read full post

Nirmalya Sengupta • Apr 20 '23

Good article.

#[must_use] is a great aid. I agree with you.

However, we can use an exact equivalent of Result in Java/Scala. It is called 'Either'. Perhaps, you already know about it. When instantiated, a value of Either can be of either the 'L' type - conventionally, indicating an error - or the 'R' type, which is the value, we are otherwise looking for.

Scala has built in Either type. In Java 8+ (I have used till Java 17), by using the fantastic 'vavr' library, 'Either' can be put to use, including the pattern-matching idioms, map(), flatMap() etc, much like Rust lets us.

I don't know Kotlin, but I assume Kotlin has something similar. Experts can comment.

YJDoc2 • Apr 23 '23

Hey, thanks for the comment! I have updated the article to mention this. I don't work much with Java/Scala so didn't know that. Does the Either type also have similar ergonomics as rust's Result? I know that types like Rust's enum (I think they are called additive data types?) exist in several other languages, but I didn't knew those have similar ergonomics as Rust's results have.

Nirmalya Sengupta • Apr 24 '23

As for ergonomics, @omidrad has already elaborated. the difference between Rust and Java. I differ slightly from his PoV and I have stated that in my response to him.

Omid Rad • Apr 24 '23

But that's different.

When you are in the ecosystem and use some dependencies, some deps use Either and some use exception. It makes things more complicated and ugly and at some point you need to handle both at the same time!

Either does exist in Rust (as library, and removed long time ago from the std lib), but IMO to use it as a way to handle errors is lame.

On top of these, there is no difference between L and R in Either, there is no Ok and Err. A library may see L as Err and another one R as Err. Also what about ? in Rust?

Anyway, they are not the same.

Nirmalya Sengupta • Apr 24 '23 • Edited

Not same, of course. But equivalent. :-)

I have steadfastly - one may say determinedly - stayed away from all checked exceptions for last few years in all my Java applications. Wherever pressed, I have wrapped the exception-throwing methods into Either returning methods.

Not easy always, as you have correctly pointed out - but demonstrably doable.

The other point you raise about L and R being not a fixed type, you are right. The convention of course, is that L is for errors and R is for acceptable values. However, nothing stops me from making L a subtype of an master Error type. The compiler does the rest.

Omid Rad • Apr 24 '23

I would say they are not equivalent also.

That's a misuse of Either to handle errors on other languages. Or let's say the best way they can do so. There are a lot around Result in Rust. There is nothing specific for error handling for Either.

The only common thing is that, both Result and Either are two-variant enums! (I don't know how exactly they called them in Java)

It's like people saying Java also has Option. But that's different between when the whole ecosystem only has Option or there is a possibility of using Options. They are not the same or equivalent.

We don't have these kinds of inconsistency, because it's a younger language. But I hope we don't have it in future also.

Paweł Kraszewski • Apr 20 '23

there is no straightforward way of doing something similar in other languages.

With all my hate to if err!=nil{}, Go has error wrapping:

var criticalError = errors.New("Serious error")
// ...
wrapped := fmt.Errorf("...%w...",criticalError,...)
// ...
parent := errors.Unwrap(wrapped)

See rollbar.com/blog/golang-wrap-and-u...

YJDoc2 • Apr 23 '23

Hey, I have updated the article to mention this. I had only seen the err != nil kind of error handling, and haven;t worked with go much, so didn't know that.

I checked the link, but I'm not sure. Does the wrapping-unwrapping provide similar ergonomics as Rust Results too?

Paweł Kraszewski • Apr 23 '23 • Edited

Does the wrapping-unwrapping provide similar ergonomics as Rust Results too?

Hell not. I hate it not without a reason. I still find Rust's error handling superior to all the other languages I use(d).

Omid Rad • Apr 24 '23

Also when you are in the ecosystem and use some dependencies, some deps use unwrapped version and some use wrapped version. It makes things more complicated!