Go Enums Suck • Hacker News Board

Re: Go Enums Suck

#31

Post by j16sdiz » Fri, Mar 01, 2024, 6:51 PM UTC

randomdata wrote: post #6

the__alchemist wrote: post #3

Go and Python have OK enums. I will use them, but they could be simpler/more expressive. This begs the question: Is there an obstacle to releasing better enums in the next Python and Go versions? If the concern is about breaking backwards compatibility, I would be OK with a new type. Is it a culture issue, ie that Python and Go programmers don't use enums much? (Chick + egg here) Rust's enums are great. No "auto" boi…

> Rust's enums are great. Rust doesn't have enums. It has sum types – that for some reason it arbitrarily decided to call enums. Sum types are great. There is a good case to be made that Go would benefit from the addition of sum types. But until that day there isn't much more you can do with enums. That's all enums are – a set of named constants.

Sum type are great, but I don't think it fits in go type system.

Re: Go Enums Suck

#32

Post by Steltek » Fri, Mar 01, 2024, 6:53 PM UTC

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

Re: Go Enums Suck

#33

Post by mseepgood » Fri, Mar 01, 2024, 6:53 PM UTC

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…

> Generics? We don't need that

You make it sound as though the developers were opposed to generics, which isn't accurate. Perhaps some in the community expressed such sentiments. The plan has always been to possibly include generics at some point, which they then did.

Re: Go Enums Suck

#34

Post by mattrighetti » Fri, Mar 01, 2024, 6:53 PM UTC

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…

> We don't need that .. (time goes on) .. okay, damn it.

To prove your point further, at the time I got the impression that most of the community was against that decision and didn't see the point in introducing generics in the language.

Re: Go Enums Suck

#35

Post by hgs3 » Fri, Mar 01, 2024, 6:53 PM UTC

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

> The title is clickbait.

The article is an advertisement for the authors own Go package that addresses the "problem."

Re: Go Enums Suck

#36

Post by kroltan » Fri, Mar 01, 2024, 6:53 PM UTC

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?

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 you try calling U methods on the contents of the list.

(Yes in C# List is a concrete vector type and in Java it is a random-access collection interface, but that is not relevant here)

Re: Go Enums Suck

#37

Post by mirekrusin » Fri, Mar 01, 2024, 6:54 PM UTC

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…

...also:

* no null safety

* working with errors

* poor type system

Re: Go Enums Suck

#38

Post by the__alchemist » Fri, Mar 01, 2024, 6:54 PM UTC

randomdata wrote: post #6

the__alchemist wrote: post #3

Go and Python have OK enums. I will use them, but they could be simpler/more expressive. This begs the question: Is there an obstacle to releasing better enums in the next Python and Go versions? If the concern is about breaking backwards compatibility, I would be OK with a new type. Is it a culture issue, ie that Python and Go programmers don't use enums much? (Chick + egg here) Rust's enums are great. No "auto" boi…

> Rust's enums are great. Rust doesn't have enums. It has sum types – that for some reason it arbitrarily decided to call enums. Sum types are great. There is a good case to be made that Go would benefit from the addition of sum types. But until that day there isn't much more you can do with enums. That's all enums are – a set of named constants.

I've heard this before, but I have a struggle understanding the abstraction.

I make heavy use of rust and Python enums (Are they both misnamed?) Those + structs are generally the base of how I structure code.

The "enums" in the article also seem to be of the same intent. Is this a "no true Scotsman" scenario?

Some research implies the difference is a True Enum involves integer mapping, while a Sum Type is about a type system. I think both the Rust and Python ones can do both. (repr(u8) and .value for Rust/Python respectively)

The use case is generally: You have a selection of choices. You can map them to an integer or w/e if you want for serialization or register addresses etc, but don't have to. Is that a sum type, or an enum? Does it matter?

Another thought:

Maybe:

  #[repr(u8)]
  enum Choice {
    A = 1
    B = 2
  }

Is an enum, while

  enum Choice {
    A(C)
    B(D)
  }

Is a sum type?

Re: Go Enums Suck

#39

Post by jimbob45 » Fri, Mar 01, 2024, 6:54 PM UTC

downWidOutaFite wrote: post #30

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.

That's a minor implementation detail that devs almost never have to think about.

You'll run into it with generic arrays[0] in Java which are reasonably common.

[0]https://www.baeldung.com/java-generic-array

Re: Go Enums Suck

#40

Post by grumpyprole » Fri, Mar 01, 2024, 6:54 PM UTC

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

Using integers to model optional behaviour sucks, whatever you choose to call it. It's what one does in assembly language and C. Even Pascal from the early 70s had type-safe enumerations.