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

41–50 of 244 posts

Re: Go Enums Suck

#41

Post by Pet_Ant »

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#.

Everything in Java is a compromise. The leaders of Java will often admit that. Josh Bloch openly talks about Java being a working man's language, a blue collar one. Every idea has to be tampered down to make it fit for Java's purpose (Bloch has said that they blew Java's complexity budget on closures and wildcards). BGGA was the real proposal for adding closures to Java, but instead it went with CICE. Java works, and it's good enough to work in, and it's got enough jobs in it. But no one thinks it's the perfect language. There are no Java equivalents of C++ or Haskell die-hards.

Re: Go Enums Suck

#42

Post by kriiuuu »

HideousKojima wrote: post #29
Zambyte wrote: post #20

Earlier quoted context omitted.

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

No, Java generics are basically syntactic sugar over casts, which is why types are erased at runtime when you're trying to debug. Performance also isn't as good as for C# generics since the Java approach limits optimizations.

Haskell also has type erasure. It’s an implementation detail, or are you saying that Haskell does not have proper generics?

Re: Go Enums Suck

#43

Post by coldtea »

Steltek wrote: post #32
coldtea wrote: post #10

Go's iota is probably one of the worst ideas in all programming languages. Not a full typesafe enum type, the same clunky "enums" (assigned constants) available in C, but they bother to implement an auto-incremented counter. So you can't depend on the enum for exhaustiveness warnings e.g. on switch statements, type checking, or correctness, but you do get a useless numeric association autogenerated with iota - so tha…

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...

Re: Go Enums Suck

#44

Post by zelos »

BugsJustFindMe wrote: post #4

> Go doesn’t technially have Enums and it is a missing feature in my book but there is a Go idiomatic way to achieve roughly the same thing. Oh, so it's a lot like Python then. > This is fine however it is nothing but an integer under the covers this means what we actually have is: Oh, so it's a lot like C++ then. > But what you notice here is we have no string representation of these Enums so we have to build that o…

C++ added enum classes a while back, though.

Re: Go Enums Suck

#45

Post by hardwaregeek »

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…

Not even Java. The entirety of programming language development. Go is a language written by very good software developers but very bad language designers. It's an entire language of "why don't you just..." statements. Errors? Why don't you just return a value? Generics? Why don't you just use duck typing? Packages? Why don't you just use vendoring?

In some cases these statements have some merit, but, as in most cases, they demonstrate that the authors didn't really do their homework before making a language. Or they willfully ignored all of these issues. I don't know which is worse.

Re: Go Enums Suck

#46

Post by pjmlp »

Pascal in its original 1970's design,

    type myEnum = (value1, value2, value3, value4)
Naturally that is too advanced and slows compile times.

Re: Go Enums Suck

#47

Post by HideousKojima »

kriiuuu wrote: post #42
HideousKojima wrote: post #29

Earlier quoted context omitted.

No, Java generics are basically syntactic sugar over casts, which is why types are erased at runtime when you're trying to debug. Performance also isn't as good as for C# generics since the Java approach limits optimizations.

Haskell also has type erasure. It’s an implementation detail, or are you saying that Haskell does not have proper generics?

I don't know the specifics of Haskell's implementation but if it's mostly the same as Java's then yeah?

Re: Go Enums Suck

#48

Post by taeric »

scrubs wrote: post #23
taeric wrote: post #13

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 a…

I'm not bent out of shape about go enum's like the OP. However when it comes to writing and reading data over networks or disk io a naked enum was never going to work anyway, not really. Then you turn to protobuf etc so one has a cross os/arch/cpu interoperability

I don't disagree, I don't think. Just wanting to float a reason simpler enums are usually preferred. In particular, you likely want to use the enum to restrict what values you will introduce into a system. You often, sadly, cannot use them to restrict what values are actually there. Which is why the place you pass them will see the raw int.

Re: Go Enums Suck

#49

Post by pjmlp »

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…

Forget about Java, not even Pascal or C enumerations from 50 years ago!

Re: Go Enums Suck

#50

Post by jurschreuder »

You should not use these enums with ints++ in security sensitive applications, because they're sensitive to rowhammer attacks.

Use uint64s with minimal bit overlap.

Maybe nice to include in this ultra-advanced enum libray

Post reply on HN