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

191–200 of 244 posts

Re: Go Enums Suck

#191

Post by pyjarrett »

ilove_banh_mi wrote: post #148

Ada has excellent enumeration types, and subtypes, and compile-time checking of case statement coverage for enum values, and an optional representation mechanism to control the binary value for each (symbolic) enum value. I'm not aware of any other language with that kind of enum type system. See e.g. https://adaic.org/resources/add_content/docs/craft/html/ch05...

Not only that, but when you define an enum you get 'Pred and 'Succ to move between values, range iteration over all values with 'Range and 'First and 'Last, string conversion with 'Image and parsing with 'Value.

Re: Go Enums Suck

#192

Post by beautron »

mattrick wrote: post #182
neilalexander wrote: post #177

Earlier quoted context omitted.

> 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 This is not true, iota is stable in its ordering. https://go.dev/ref/spec#Iota

I think they may be referring to if someone accidentally changes the ordering, either by inserting a new variant between two existing ones or by shuffling the order of the existing variants the value can change and cause problems.

Yes, but even with that interpretation, they claimed something much stronger:

> The encoded value can change any time you re-compile your program

Any value (not just enums) can change any time you re-compile your program, if some programmer goes in and messes it up.

The real, much softer criticism would be that Go requires its programmer's to understand the potential consequences of inserting or shuffling enum values (where iota is involved). It's a much weaker case against iota than what they stated.

Re: Go Enums Suck

#193

Post by scosman »

Jtsummers wrote: post #165
scosman wrote: post #160

Earlier quoted context omitted.

Faiiir. Nothing was net new concept. But the package they made was quite unique. Garbage collected but always native. No thread access, native channels and coroutines instead. Defer is pretty much net new in language design terms. No while loop?!? “If err != nil”!!? Lots of bold ideas, in a good package, and it worked so well. Calling the evolution boneheaded dismisses how hard it is to make so many opinionated bets…

Just pointing out that it was not really as novel as you seem to believe it was at the time it came out. > Garbage collected but always native. Ok, sure. There were no other native garbage collected languages. Ignoring history, this is true. > No thread access, native channels and coroutines instead. If we ignore history again, also new with Go. > Defer is pretty much net new in language design terms. I can't think o…

^ thread

Re: Go Enums Suck

#194

Post by ithkuil »

ilove_banh_mi wrote: post #148

Ada has excellent enumeration types, and subtypes, and compile-time checking of case statement coverage for enum values, and an optional representation mechanism to control the binary value for each (symbolic) enum value. I'm not aware of any other language with that kind of enum type system. See e.g. https://adaic.org/resources/add_content/docs/craft/html/ch05...

Rust I think covers most if not all of Ada features you mentioned

Re: Go Enums Suck

#195

Post by Thaxll »

hardwaregeek wrote: post #129
mseepgood wrote: post #55

Earlier quoted context omitted.

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

Go interfaces are not ducked typed.

Re: Go Enums Suck

#196

Post by Thaxll »

pjmlp wrote: post #136
mseepgood wrote: post #125

Earlier quoted context omitted.

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

Appeal to authority. Also note that none of Wirth's Oberon variants have achieved any commercial success. Modula-2, which had enums, on the other hand did enjoy a limited success, across UNIX, PC and Amiga, and is nowadays even available as standard GCC fronted. Go would have been a failure if the authors weren't Google employees, like it happened with their Limbo.

Dart is a really good example. A dead language but somehow it was created by Google, what gives?

Re: Go Enums Suck

#197

Post by Thaxll »

pkulak wrote: post #167
StevePerkins wrote: post #133

Earlier quoted context omitted.

I would wager that the vast majority of backend software jobs are for people writing REST API microservices, exchanging JSON, with a mindset that is more practical and "blue-collar" than academic. Golang is an absolutely ideal language for writing REST API microservices, that exchange JSON, with a practical and blue-collar mindset. Plus it compiles to small-ish native executables. Which renders Docker superfluous in…

> Golang is an absolutely ideal language for writing REST API microservices Those are strong words for a language with all the flaws I just mentioned. :D Yes, green threads are great for network programming, but it's not the only language with them, and one feature does not make it "ideal". If I had to pick the best networking language... I'd probably say Elixir. But even if we agree that it's ideal, it doesn't chang…

Elixir performance is pretty average and it's not a statically typed language, things will blow up at runtime.

Re: Go Enums Suck

#198

Post by coffeebeqn »

danenania wrote: post #88
zoogeny wrote: post #62

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…

I'm working on an LLM project in Go and the term "context" is overloaded to the hilt--I use it to refer to the LLM context as well as Go's `context.Context` which I'm using all over the place. It's made worse since the most natural plural of context is... context. My solution is to use `ctx` for Go context, `contexts` for arrays of LLM context structs, and `contextPart` for individual context structs. "model" is anot…

Context is actually one of my least favorite parts of go. I wish they at least reimplemented it with generics so it’s not just a unlabeled box of maybe some stuff that can also cancel things

Re: Go Enums Suck

#199

Post by coffeebeqn »

thegeekpirate wrote: post #68
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.

That looks nothing like go. I wonder why even call it go+ at that point

Re: Go Enums Suck

#200

Post by xigoi »

randomdata wrote: post #126
samatman wrote: post #113

Earlier quoted context omitted.

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.

But neither C nor Go have type-safe enums.
Post reply on HN