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

Go Enums Suck

zarl.dev

Post reply on HN
Print view View original

11–20 of 244 posts

Re: Go Enums Suck

#11

Post by randomdata »

mseepgood wrote: post #9

Go doesn't have enums and as such they cannot suck. Something that is non-existent can't be good or bad. The title is clickbait. Go has constants, and they have a great feature for defining constants (iota).

> Go has constants

That's literally what enums are: A set of named constants.

You might be thinking of what is traditionally known as sum types, which some people have recently started calling enums[1]. Indeed, Go does not have sum types.

[1] Presumably because of Rust using the wrong term when specifying its sum types

Re: Go Enums Suck

#12

Post by coldtea »

SamWhited wrote: post #8

I generally agree that this is a big problem with Go, so I don't want to quibble too much, but the author acknowledges that the language doesn't have enums and that they're just trying to use this feature like enums (TBF, this is common advise on the internet and a lot of code does this): instead the author should be thinking "how do I solve this problem without enums since they don't exist?" I'd be willing to bet th…

>instead the author should be thinking "how do I solve this problem without enums since they don't exist?"

Which is exactly what they do in the post.

They still have every reason to complain about Go's oft suggested lame substitute.

Re: Go Enums Suck

#13

Post by taeric »

A thing that so many enum solutions miss is that you have to have a path for a value outside of the current definition, or you lose a lot of flexibility in compatibility with any data that crosses wires or disks. Sounds fine for a lot of cases, of course, but in a world of mixed deployment fleets working on data, you pretty much have to have a way to allow a value that is not part of your current definition, or you are basically placing a "poison pill" on your system.

Re: Go Enums Suck

#14

Post by kevmo314 »

> Anywhere that accepts an Operation Enum type will just as happily accept an int. This is a real pain as it almost completely negates the work we have done here.

Is this a real problem? If there's a function signature that accepts `Operation`, the caller must explicitly cast the `int` to `Operation`. At that point, it's the caller's own fault.

So I'm not really following what this is solving. As demonstrated in the article, sometimes you want string constants, sometimes you want `iota`, other times you want `1 << iota`. I like that Go doesn't dictate which I have to use if I declare an "enum".

Re: Go Enums Suck

#15

Post by klysm »

sgift wrote: post #5

I love Go. Especially how the devs stubbornly refuse to learn anything from Java, but stumble boneheaded into everything that Java solved over the years. Generics? We don't need that .. (time goes on) .. okay, damn it. Here! Generics! Enums? We don't need that, just do iota/integers! How long will it be this time until the Go devs accept that Java Enums are a safer and better abstraction over integers for the cases w…

I think boneheaded is a good way to describe the evolution of go. It seems like the original authors were convinced most of the complexity of modern languages was unjustified and have slowly proven themselves incorrect over the years

Re: Go Enums Suck

#16

Post by khazhoux »

randomdata wrote: post #11
mseepgood wrote: post #9

Go doesn't have enums and as such they cannot suck. Something that is non-existent can't be good or bad. The title is clickbait. Go has constants, and they have a great feature for defining constants (iota).

> Go has constants That's literally what enums are: A set of named constants. You might be thinking of what is traditionally known as sum types, which some people have recently started calling enums[1]. Indeed, Go does not have sum types. [1] Presumably because of Rust using the wrong term when specifying its sum types

The article is about enums, which are lacking in Go.

Re: Go Enums Suck

#17

Post by neonsunset »

sgift wrote: post #5

I love Go. Especially how the devs stubbornly refuse to learn anything from Java, but stumble boneheaded into everything that Java solved over the years. Generics? We don't need that .. (time goes on) .. okay, damn it. Here! Generics! Enums? We don't need that, just do iota/integers! How long will it be this time until the Go devs accept that Java Enums are a safer and better abstraction over integers for the cases w…

Java generics aren't even proper generics. For that better look at Rust and C#.

Re: Go Enums Suck

#18

Post by randomdata »

khazhoux wrote: post #16
randomdata wrote: post #11

Earlier quoted context omitted.

> Go has constants That's literally what enums are: A set of named constants. You might be thinking of what is traditionally known as sum types, which some people have recently started calling enums[1]. Indeed, Go does not have sum types. [1] Presumably because of Rust using the wrong term when specifying its sum types

The article is about enums, which are lacking in Go.

No, Go definitely has enums. It is sum types (that some people have recently started calling enums) that Go lacks.

Re: Go Enums Suck

#19

Post by j16sdiz »

SamWhited wrote: post #8

I generally agree that this is a big problem with Go, so I don't want to quibble too much, but the author acknowledges that the language doesn't have enums and that they're just trying to use this feature like enums (TBF, this is common advise on the internet and a lot of code does this): instead the author should be thinking "how do I solve this problem without enums since they don't exist?" I'd be willing to bet th…

I can't really think how this could be done.

Other languages either substitute enum with primitive type, string, or use strong type system tricks.

Go do duck typing, .. so..

Re: Go Enums Suck

#20

Post by Zambyte »

neonsunset wrote: post #17
sgift wrote: post #5

I love Go. Especially how the devs stubbornly refuse to learn anything from Java, but stumble boneheaded into everything that Java solved over the years. Generics? We don't need that .. (time goes on) .. okay, damn it. Here! Generics! Enums? We don't need that, just do iota/integers! How long will it be this time until the Go devs accept that Java Enums are a safer and better abstraction over integers for the cases w…

Java generics aren't even proper generics. For that better look at Rust and C#.

In what sense? Because they only apply to non-primitive types?
Post reply on HN