Enums in Go
dizzy.zone
Enums in Go
1–10 of 57 posts
Re: Enums in Go
#2I wonder if go ever will get some sort of enum type? Or if int/string based types will be the goto way?
Re: Enums in Go
#3I wonder if go ever will get some sort of enum type? Or if int/string based types will be the goto way?
If there is one thing that I find missing is proper enum support in the Go language.
There are quite a few subtle caveats you can run into without proper support in the language like the article mentions. (E.g. Using iota, passing in an undefined enum)
Re: Enums in Go
#4I wonder if go ever will get some sort of enum type? Or if int/string based types will be the goto way?
If there is one thing that I find missing is proper enum support in the Go language. There are quite a few subtle caveats you can run into without proper support in the language like the article mentions. (E.g. Using iota, passing in an undefined enum)
This might be a very simple and ignorant thought, but I'd be fine if they completely worked the same as Rust's enum's. [if let] is such a powerful feature, along with match arms.
Re: Enums in Go
#5Earlier quoted context omitted.
If there is one thing that I find missing is proper enum support in the Go language. There are quite a few subtle caveats you can run into without proper support in the language like the article mentions. (E.g. Using iota, passing in an undefined enum)
This might be a very simple and ignorant thought, but I'd be fine if they completely worked the same as Rust's enum's. [if let] is such a powerful feature, along with match arms.
That’s not an enumeration like the parent and grandparent are discussing (think of a collection of consts), that’s a tagged union you’re talking about. Confusing because rust used the name enum in their syntax for this (Haskell calls it data - well, Haskell uses data in their syntax for both product and sum types).
Re: Enums in Go
#6Re: Enums in Go
#7Earlier quoted context omitted.
If there is one thing that I find missing is proper enum support in the Go language. There are quite a few subtle caveats you can run into without proper support in the language like the article mentions. (E.g. Using iota, passing in an undefined enum)
This might be a very simple and ignorant thought, but I'd be fine if they completely worked the same as Rust's enum's. [if let] is such a powerful feature, along with match arms.
Rust got those basic type system and pattern matching things so incredibly right it’s not even funny. I even like Go more for other reasons but I still cringe every time I have to use the error prone hacks mentioned in this post. Not to mention the largest source of noise: `if err != nil`, which Rust solved so elegantly using partly their enum types.
Re: Enums in Go
#8I'm implementing a somewhat complex software in both Go and Rust.
The Rust version is bith shorter and more readable - and probably more efficient - thanks to Rust enums and Rust error handling. I don't understand why golang doesn't copy Rust here. The error handling in particular could be a very simple change.
I am not a huge fan of go:generate and similar projects. They add a level of unknown that goes against the core Golang design values.
Re: Enums in Go
#9Earlier quoted context omitted.
If there is one thing that I find missing is proper enum support in the Go language. There are quite a few subtle caveats you can run into without proper support in the language like the article mentions. (E.g. Using iota, passing in an undefined enum)
This might be a very simple and ignorant thought, but I'd be fine if they completely worked the same as Rust's enum's. [if let] is such a powerful feature, along with match arms.
Sure, but "the same as Rust's enums" including a mention of pattern matching, is a really big expenditure on the novelty budget from the point of view of Go. What Rust does there is perfectly normal... for an ML. But before Rust you didn't really see an ML down there counting CPU cycles, so this wasn't even on the radar when Go was invented.
I think to do that you'd probably give up a lot of the simplicity Go is aiming for. I personally think that simplicity is somewhat illusion (Amos' "I want off Mr. Golang's Wild Ride" https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... says it better than I could) but we should be clear that it's not that Go aimed to do what I want and missed but that it was never interested in that at all. An F1 car doesn't want to be useful for taking the kids to school, so it's silly if we're scoring it poorly for lack of child seat fixtures.
Re: Enums in Go
#10I really miss value enums from Rust while working with Go, but overall I find Go more intuitive. Didn't know there was a way of auto-generating with stringer, so thanks for the information!