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

121–130 of 244 posts

Re: Go Enums Suck

#121

Post by taeric »

eptcyka wrote: post #112
taeric wrote: post #48

Earlier quoted context omitted.

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.

Yeah, but then should structs ever have a bounded size? Someone might well have gone and done did added a couple of fields to a struct over the wire.

I think I touched on what I feel is the right answer here. The data is separate from the enum. That part is clear and I don't think anyone really disagrees.

What, then, is the enum for? It is specifically to restrict what your code will do. To that end, it is a good way to restrict data your code can introduce. It is not a restriction on what is happening outside of your code, though.

You can, of course, make similar arguments for structs. Or really any data in the code. How do you know your number won't go over some arbitrary size?

Enums are, largely, the most restrictive data in code. Which is why we discuss them more, I think. If folks did work with more big numbers, I'm sure we would be more curious on why things don't act like common lisp where big numbers basically work with no extra work.

Re: Go Enums Suck

#122

Post by pjmlp »

mseepgood wrote: post #104
pjmlp wrote: post #46

Pascal in its original 1970's design, type myEnum = (value1, value2, value3, value4) Naturally that is too advanced and slows compile times.

Wirth regretted it later and didn't add it to Oberon. Quote from "From Modula to Oberon": "Enumeration types appear to be a simple enough feature to be uncontroversial. However, they defy extensibility over module boundaries. Either a facility to extend given enumeration types has to be introduced, or they have to be dropped. A reason in favour of the latter, radical solution was the observation that in a growing num…

I know, and there is a reason why my favourite descendant from Oberon is Active Oberon, and not what Wirth pursued after 1992.

Oberon-07 minimalism doesn't make Go better.

Re: Go Enums Suck

#123

Post by pjmlp »

leosanchez wrote: post #81
pjmlp wrote: post #46

Pascal in its original 1970's design, type myEnum = (value1, value2, value3, value4) Naturally that is too advanced and slows compile times.

> Naturally that is too advanced and slows compile times. Sarcasm ?

On the spot.

Re: Go Enums Suck

#125

Post by mseepgood »

pjmlp wrote: post #122
mseepgood wrote: post #104

Earlier quoted context omitted.

Wirth regretted it later and didn't add it to Oberon. Quote from "From Modula to Oberon": "Enumeration types appear to be a simple enough feature to be uncontroversial. However, they defy extensibility over module boundaries. Either a facility to extend given enumeration types has to be introduced, or they have to be dropped. A reason in favour of the latter, radical solution was the observation that in a growing num…

I know, and there is a reason why my favourite descendant from Oberon is Active Oberon, and not what Wirth pursued after 1992. Oberon-07 minimalism doesn't make Go better.

You can disagree with design philosophies, but Wirth and the Go designers probably have thought more about these things than you.

Re: Go Enums Suck

#126

Post by randomdata »

samatman wrote: post #113
pkulak wrote: post #80

Earlier quoted context omitted.

Go is in this weird middle ground where it's modeled after C, so it's got things like no enums, return codes for errors, mutable everything, nulls, and pointers (that don't support arithmetic, so it's really just this "*" sigil that you have to remember to use sometimes), but it's also fully garbage collected and has built-in, stackful green threads. I have no idea what it's actually trying to be.

C does have enums. Not trying to detract from your point, which I agree with, but enums are definitely a thing, which C has.

> C does have enums.

Then again, so does Go. Go doesn't have an enum keyword like C, but that isn't what defines enums.

Re: Go Enums Suck

#127

Post by 015a »

`iota` is maybe the only language feature of Go that I would actually support removing. Obviously, they never will because it would be a breaking change. Its just so vestigial. There's literally no reason to use it, and a very big reason why you shouldn't: The encoded value can change any time you re-compile your program, so you can't actually use it for anything where the value of the enum leaves the process that instantiated it (e.g. marshaling to JSON and sending over the wire). That's a terribly poor characteristic for a feature in a "systems" (emphasis on plural) programming language to have, one would think.

Re: Go Enums Suck

#128

Post by IshKebab »

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

> rigid and encompassing

Rigid makes it sound bad. I would suggest "reliable" instead.

Re: Go Enums Suck

#129

Post by hardwaregeek »

mseepgood wrote: post #55
hardwaregeek wrote: post #45

Earlier quoted context omitted.

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

> Generics? Go does have generics, though. > Why don't you just use duck typing? Go doesn't have duck typing. It has structural typing, which is not duck typing. Duck typing is dynamic typing (at runtime), structural typing is static (at compile time). > Packages? Go does have packages. > Why don't you just use vendoring? In Go it's recommended to use versioned modules, not vendoring.

It has generics now. It took them a solid 10 years to get it. Packaging took them what, 8 years? They had that ridiculous GOROOT stuff for the longest time. And interfaces are basically duck typed.

Re: Go Enums Suck

#130

Post by nzach »

mojuba wrote: post #94

func (o Operation) IsValid() bool { if o == Unknown { return false } return true } Why, oh why don't people just write return o != Unknown This is so common in the code that I'm seeing on the Internet, on GitHub etc. Is it because people don't understand booleans?

This is in line with 'guard clauses' and this is why it is accepted as idiomatic code.

For this example we only have a single condition but as soon as you add more conditions it start to get out of hand.

I prefer the original code because it makes the codebase as a whole easier to read. But I don't think there are any 'hard facts' to support using either of these styles over the other in these simple cases.

Post reply on HN