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

61–70 of 244 posts

Re: Go Enums Suck

#61

Post by andreimackenzie »

Scubabear68 wrote: post #28

It has always been surprising to me how primitive Go really is, for no really good reason. I understand the evolution of C, it made perfect sense back when it was invented. And the limitations were necessary due to the wide array of architectures and extremely limited computers of the time in every dimension (CPU speed, IO speed, RAM size, disk size, etc). Many of those dimensions have been improved by several orders…

Simplicity is a feature. Sure, how complicated can effective enums really be, but Go's general philosophy is to think hard (& sometimes for a long time) before adding every bell and whistle.

I have a far easier time delving in to previously unknown Go code for the first time compared to something like Scala (or even Java). Go is a solid language for those who value that and want to enable the experience for others.

Re: Go Enums Suck

#62

Post by zoogeny »

I have a totally tangential ramble queued up on this topic.

I like philosophy and I read it as a total amateur. Naming is a big topic in modern philosophy [1] with a huge amount of depth. I think of it in terms of my naïve understanding of Wittgenstein's later work and the idea that the meaning of a word actually comes from its usage within the context of a set of collaborating agents.

If I say to a programmer "use a vector", that will mean something specific if we are writing C++ and I want to use a resizable array. And it could mean something totally different in the context of a 3d rendering engine.

I think of how often I see words like "Context", "Session", "Kernel" and all of their myriad uses.

So I see articles like this as just a pointless argument because we are crossing some boundary between distinct language games. The author of this article thinks "Enum" means one thing. But it is actually the case that "Enum" is unspecified outside of some particular context. And in this case, the author is bringing some outside context and trying to reuse it inappropriately.

1. https://en.wikipedia.org/wiki/Naming_and_Necessity

Re: Go Enums Suck

#63

Post by geodel »

coldtea wrote: post #12
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.

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

Well, yeah, this is also the reason they deserve quite a bit of ridicule from actual Go users.

Re: Go Enums Suck

#64

Post by randomdata »

grumpyprole wrote: post #53
randomdata wrote: post #18

Earlier quoted context omitted.

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

Go does not model enums as separate types (like e.g. Pascal), they are essentially just integers like C.

No, Go enums are definitely separate types. Sure, technically there is also an integer (or some other base representation) hidden in there somewhere, but that's what an enumeration is. Without that you don't have an enum.

Re: Go Enums Suck

#65

Post by mseepgood »

klysm wrote: post #15
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

> convinced most of the complexity of modern languages was unjustified

You don't think that most of the complexity of modern languages is unjustified?

Re: Go Enums Suck

#66

Post by blibble »

kroltan wrote: post #36
Zambyte wrote: post #20

Earlier quoted context omitted.

In what sense? Because they only apply to non-primitive types?

I'm assuming because of erasure? In C#, List and List follows the same assignment rules as T and U, and at runtime are represented by distinct types. That means that going from List to object to List causes a runtime error at the point of casting. In Java, every generic type is erased to object at runtime, so the runtime type is just List, and you could cast List to object to List and only get an error later, when yo…

if T and U don't have the same erasure the compiler will forbid the cast

if they do the compiler will warn you that an List to List cast is naughty

but in that case the only methods you can call on it are that of the erased type anyway

in practice I don't think I've ever seen a bug as a result of this type of erasure (and I've probably worked with at least several million lines of Java)

Re: Go Enums Suck

#67

Post by sgift »

Zambyte wrote: post #20
neonsunset wrote: post #17

Earlier quoted context omitted.

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?

To allow backward compatibility Java introduced Generics with type erasure, which in short means they only exist at compile-time, not at runtime (there are some hacks around that, which various devs have used with great success to still get the information). That is another reason to just start with Generics from the beginning if you design a new language, so you won't have compatibility problems when you introduce them. It's not like Generics were a controversial feature when Go came out.

C#, which is often cited as an example for "generics done right" chose another path, which allowed generics at runtime - they made a hard break and just threw backward compatibility out of the window iirc. The reason Javas designers didn't do that is not only introduced generics far later in its lifecycle, but Java also has always followed the hard rule that breaking backward compatibility is something which should only ever used as a last resort and never between two versions directly following each other.

Re: Go Enums Suck

#68

Post by thegeekpirate »

parhamn wrote: post #54

Anyone writing a compiles to go, go++ yet? There are generators for better enums, sum types, and more. Bring them all together! I'm only kinda joking. Im also curious now if the Typescript checker was written in a way that it could be adapted to new languages easily.

https://github.com/goplus/gop, but they go slightly too overboard imo.

Re: Go Enums Suck

#69

Post by preommr »

coldtea wrote: post #43
Steltek wrote: post #32

Earlier quoted context omitted.

I love iota! It comes in handy everywhere. Don't serialize to raw integers unless you absolutely have to. Serialize to a string value: it's future/oopsie proof and helps with debugging. The nature of iota is pushing people away from bad habits. But yes, getting warnings about missing enums in switch statements is very handy. But Golang's type system never aspired to be as rigid and encompassing as C++, Haskell, Rust,…

> But Golang's type system never aspired to be as rigid and encompassing as C++, Haskell, Rust, etc. Well, didn't have to aspire to all that to at least make an effort to be more helpful, especially in trivial aspects, like having an actual enumerated type, or an Optional/Error type...

I don't think you understand how minimalist Golang is... the std lib only has room for anything you would ever need for a web service including a full web server, builtins like hashmaps, a bunch of things for concurrent programming like channels, go routines, etc. There's also language features like returning tuples and destructuring them which is actually more advanced than it's peers.

To include an optional type would be against go's identity.

Re: Go Enums Suck

#70

Post by marklar423 »

If you're using protobufs anyway, you can get also get this functionality generated by using a proto enum: https://protobuf.dev/reference/go/go-generated/#enum. It works really nicely and has all the features mentioned in the article.

One added benefit is it serializes/deserializes safely (even when you add / remove values), so you can persist and read back values without a problem - even to a different language.

Post reply on HN