Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enums in Rust – and why they feel better

shuttle.rs

Post reply on HN
Print view View original

11–20 of 80 posts

Re: Enums in Rust – and why they feel better

#11

Post by fifticon »

ongy wrote: post #9
pjmlp wrote: post #7

Earlier quoted context omitted.

Java enums are also quite powerful versus what C, C++ and C# can do. They are real objects, can have associated data and methods. So if they are surprised by Rust, haven't learnt Java properly

I Haven't used java in ages. Though from a quick search, it's still just scalar/unary values. Rhough one of the better implementations of those. But the big advantage of the more sum type Style enums rust provides is the ability to nest values in them while preserving type safety guarantees. So I still see them as miles better as a language concept.

erh no, those in java allow you to do just that. It is one of my favorite features of java. In essence, you get to embed multiple synchronized maps inside a java enum (if you want to). All handled 'invisibly' for you.

Re: Enums in Rust – and why they feel better

#12

Post by rgoulter »

The term "Newtype" more specifically describes a wrapper around a single type. It's like an alias.

It's incorrect to describe an enum with two variants as a 'newtype'.

I think the example was misunderstood from https://rust-unofficial.github.io/patterns/patterns/behaviou... (which uses Password, but doesn't use an enum with two variants).

The use of enums in the example is fine; but it's not a "newtype".

Re: Enums in Rust – and why they feel better

#13

Post by papercrane »

ongy wrote: post #9
pjmlp wrote: post #7

Earlier quoted context omitted.

Java enums are also quite powerful versus what C, C++ and C# can do. They are real objects, can have associated data and methods. So if they are surprised by Rust, haven't learnt Java properly

I Haven't used java in ages. Though from a quick search, it's still just scalar/unary values. Rhough one of the better implementations of those. But the big advantage of the more sum type Style enums rust provides is the ability to nest values in them while preserving type safety guarantees. So I still see them as miles better as a language concept.

Java enums are a class with a fixed number of instances.

The thing in Java that is closest to Rust enum's would be sealed classes, which was a preview feature in Java 15 and finalized and released with Java 17.

https://openjdk.org/jeps/409

Re: Enums in Rust – and why they feel better

#14

Post by Ygg2 »

fifticon wrote: post #11
ongy wrote: post #9

Earlier quoted context omitted.

I Haven't used java in ages. Though from a quick search, it's still just scalar/unary values. Rhough one of the better implementations of those. But the big advantage of the more sum type Style enums rust provides is the ability to nest values in them while preserving type safety guarantees. So I still see them as miles better as a language concept.

erh no, those in java allow you to do just that. It is one of my favorite features of java. In essence, you get to embed multiple synchronized maps inside a java enum (if you want to). All handled 'invisibly' for you.

Still, you get to see all fields from all variants, while Rust variants are more isolated.

Re: Enums in Rust – and why they feel better

#15

Post by Shish2k »

hurril wrote: post #3

> A commonly said piece of feedback from someone who's learning Rust as a second language tends to be that enums are far better supported in Rust than any other language. This is nonsense. I doubt that this is common feedback and it is just not correct that it is far better supported in Rust than in any other language. Why would anyone say that? Rust pretty much has support for ADTs, sum types and product types. Just…

> Haskell, Scala, F#, OCaml, etc.

Rust is the first not-weirdass-academic-wtf language to have these features ;)

(I love functional programming and apply the functional approach no matter what language I’m using - but why is it that functional languages are always so deeply down the academic rabbithole that they think eg “car” and "cdr” are intuitive names for “retrieve the first element of a list” and “retrieve the rest of the list” functions??)

Re: Enums in Rust – and why they feel better

#16

Post by flohofwoe »

hurril wrote: post #4
bruce343434 wrote: post #2

I always hated the name. You're not enumerating anything. You are picking a variant, encoding a choice. Maybe "sum type" is too "monad", but surely "variant record" or even "variant" would have been a better name.

While I agree with you, I can understand going with enum so that they don't scare away the C and C++ crowd with being too fartsy with theoretic stuff.

It is especially confusing for C and C++ coders, because Rust enums are a completely different thing than C enums, which makes the naming choice worse than just inventing a new name.

Better names would be "tagged union" (which is spot-on descriptive - because it *is* a union with a tag slapped on - but "tagged_union" of course is a bit unwieldy as keyword) or "variant" (which is the name for that thing in C++ and elsewhere since forever - it's not like Rust invented those tagged-union-thingies, it just added some convenient syntax sugar to the language to deal with them).

Re: Enums in Rust – and why they feel better

#18

Post by lawn »

hurril wrote: post #3

> A commonly said piece of feedback from someone who's learning Rust as a second language tends to be that enums are far better supported in Rust than any other language. This is nonsense. I doubt that this is common feedback and it is just not correct that it is far better supported in Rust than in any other language. Why would anyone say that? Rust pretty much has support for ADTs, sum types and product types. Just…

Obvious they would say that because they're not familiar with the other languages. Like it or not they probably come from Python/C++/JavaScript or similar.

Re: Enums in Rust – and why they feel better

#19

Post by randomdata »

hurril wrote: post #4
bruce343434 wrote: post #2

I always hated the name. You're not enumerating anything. You are picking a variant, encoding a choice. Maybe "sum type" is too "monad", but surely "variant record" or even "variant" would have been a better name.

While I agree with you, I can understand going with enum so that they don't scare away the C and C++ crowd with being too fartsy with theoretic stuff.

In practice, now C developers get to hear from the Rust crowd that C doesn't have enums because what C has is unlike Rust "enums".

Re: Enums in Rust – and why they feel better

#20

Post by Sharlin »

fifticon wrote: post #11
ongy wrote: post #9

Earlier quoted context omitted.

I Haven't used java in ages. Though from a quick search, it's still just scalar/unary values. Rhough one of the better implementations of those. But the big advantage of the more sum type Style enums rust provides is the ability to nest values in them while preserving type safety guarantees. So I still see them as miles better as a language concept.

erh no, those in java allow you to do just that. It is one of my favorite features of java. In essence, you get to embed multiple synchronized maps inside a java enum (if you want to). All handled 'invisibly' for you.

No, Java enums can contain data but do so in a manner orthogonal to Rust enums. Java enums are not sum types; each variant is simply a (`final`) instance of the enum type which, mostly, is just a regular class type with a private constructor so that no other instances can be created. All variants have the same shape and the author of the enum decides what data the variants contain.

Rust enums are sum types, which means that each variant can have a totally different shape and contain different data, and it's the user of the enum that supplies the data when they create an instance of a variant. This quintessential use case for sum types not possible with Java enums (although it is now sort of possible with records and sealed traits):

    enum Result {
      Ok(T),
      Err(E)
    }
Post reply on HN