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

21–30 of 80 posts

Re: Enums in Rust – and why they feel better

#21

Post by CodesInChaos »

pjmlp wrote: post #7
ongy wrote: post #5

Earlier quoted context omitted.

Because many people start learning in one of the industry incumbent, not necessarily good by design languages. Java, C, C++, python, Javascript, go... As a second language is a quite different selector than after education in language design or excursions to functional programming.

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

Java enums store the associated data once per option, while Rust enums store it per value. So they're very different. You couldn't model Rust's `Option` or `Result` as a java enum.

Re: Enums in Rust – and why they feel better

#22

Post by noam_k »

sshine wrote: post #17

Better enums, but not better ADTs. I didn’t write a lot of compilers in Rust yet, but I find it limiting that you can’t pattern match across a Box , and all ASTs require boxing for recursive references.

I think what you want is to enable box_patterns[0]. I have no idea why it isn't stable yet.

[0] https://doc.rust-lang.org/beta/unstable-book/language-featur...

Re: Enums in Rust – and why they feel better

#23

Post by flohofwoe »

kibwen wrote: post #8
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.

In early Rust, the keyword was `tag`. In order to improve familiarity with C++ programmers, bikeshedding raged between `enum` and `union` for years before finally landing on the former.

TBH it's kinda funny how they narrowed it down to two options and then went with the "obviously" wrong option (also to get C++ programmers on board, wouldn't the obvious name not be "variant"?

I really wonder how that decision making progress looked like :)

Re: Enums in Rust – and why they feel better

#24

Post by drexlspivey »

sshine wrote: post #17

Better enums, but not better ADTs. I didn’t write a lot of compilers in Rust yet, but I find it limiting that you can’t pattern match across a Box , and all ASTs require boxing for recursive references.

> I didn’t write a lot of compilers in Rust yet

what a pleb

Re: Enums in Rust – and why they feel better

#25

Post by azzentys »

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…

I think that's one of the important features why I LOVE Rust! I recently wrote a Chip-8 emulator and creating an enum with all commands = AMAZING!

(I come from C/Embedded world)

Re: Enums in Rust – and why they feel better

#26

Post by brandonmenc »

pjmlp wrote: post #6
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…

There is a group of folks that had learnt these features via Rust, and for whatever reason always praise Rust for "inventing" them.

A similar thing happened about 15 years ago with Ruby and “metaprogramming”.

Re: Enums in Rust – and why they feel better

#28

Post by jowea »

flohofwoe wrote: post #23
kibwen wrote: post #8

Earlier quoted context omitted.

In early Rust, the keyword was `tag`. In order to improve familiarity with C++ programmers, bikeshedding raged between `enum` and `union` for years before finally landing on the former.

TBH it's kinda funny how they narrowed it down to two options and then went with the "obviously" wrong option (also to get C++ programmers on board, wouldn't the obvious name not be "variant"? I really wonder how that decision making progress looked like :)

Union did end up meaning another thing that is just like C union and just as unsafe.

Re: Enums in Rust – and why they feel better

#29

Post by ForkMeOnTinder »

noam_k wrote: post #22
sshine wrote: post #17

Better enums, but not better ADTs. I didn’t write a lot of compilers in Rust yet, but I find it limiting that you can’t pattern match across a Box , and all ASTs require boxing for recursive references.

I think what you want is to enable box_patterns[0]. I have no idea why it isn't stable yet. [0] https://doc.rust-lang.org/beta/unstable-book/language-featur...

I believe it's not stable because it gives std::boxed::Box special treatment in the language. They'd rather find a solution that could work equally well for smart pointers defined outside of std.

Box patterns are likely to be superseded by one of these:

https://github.com/rust-lang/rust/issues/42640

https://github.com/rust-lang/rust/issues/87121

Re: Enums in Rust – and why they feel better

#30

Post by steveklabnik »

flohofwoe wrote: post #23
kibwen wrote: post #8

Earlier quoted context omitted.

In early Rust, the keyword was `tag`. In order to improve familiarity with C++ programmers, bikeshedding raged between `enum` and `union` for years before finally landing on the former.

TBH it's kinda funny how they narrowed it down to two options and then went with the "obviously" wrong option (also to get C++ programmers on board, wouldn't the obvious name not be "variant"? I really wonder how that decision making progress looked like :)

Don’t forget rust also has unions. Not using the name “union” for a feature that’s different than unions doesn’t feel “obviously wrong” to me.
Post reply on HN