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

141–150 of 244 posts

Re: Go Enums Suck

#141

Post by randomdata »

grumpyprole wrote: post #120
randomdata wrote: post #64

Earlier quoted context omitted.

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.

Creating new types wrapping int is not really the same thing. It's not a closed set. Presumably one could define additional overlapping constants with the same integer type elsewhere?

Go types do not support value constraints, no. That has nothing to do with enums, though. That's a different feature altogether.

Re: Go Enums Suck

#142

Post by pjmlp »

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.

They already exist, D, C#, Odin, Nim... no need to insist when the community is so down into minimalism.

Re: Go Enums Suck

#143

Post by zarldev »

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?

Hey did you read to the bottom of the article. It shows that that was just a temporary solution, the real invalid code is

func (t operation) IsValid() bool { _, ok := strOperationMap[s] return ok }

Tbh it has been updated to us an array instead for string indexing.

Re: Go Enums Suck

#144

Post by [deleted] »

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.

[deleted]

Re: Go Enums Suck

#145

Post by tgv »

StevePerkins wrote: post #133
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.

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…

Completely true. And most of the time, I enjoy writing go. But the enums are weak. However, if the Go team wants to tackle an important addition to the language, it should be non-nillable pointers. No need for Option sum types, just a type annotation that says it cannot be nil (but can be assigned a nil type if you've tested it for not being nil). I've thought about building a linter (like the Uber one), but the way the types in the syntax tree are resolved makes it too complex for a small project.

Re: Go Enums Suck

#146

Post by richbell »

preommr wrote: post #69
coldtea wrote: post #43

Earlier quoted context omitted.

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

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

I can't tell if this is sarcasm.

If it isn't, I don't see how what you've mentioned is minimalistic or how adding an option type would be against Go's identity.

Re: Go Enums Suck

#147

Post by [deleted] »

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?

[deleted]

Re: Go Enums Suck

#148

Post by ilove_banh_mi »

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

Re: Go Enums Suck

#149

Post by zarldev »

llmblockchain wrote: post #58

It's kind of strange to see them complain about enums and then promote a DSL-specific tool they made for generating enums. At the same time, Go has generators built in and can generate enum tables, enum to strings, and other things they have shown. I am unsure why they didn't do it the "Go" way.

DSL? The go way is to use go generate I would say and it can be used with go:generate, I would like to use the AST lib to parse go files to remove the need for any json and to be more like the cmd stringer tool.

Re: Go Enums Suck

#150

Post by Steltek »

DinaCoder99 wrote: post #102
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,…

Why use ints in the first place if what you really want is strings?

Integers are far faster, smaller, and golang is strongly typed. Once you're past the serialization phase, strings have many disadvantages.
Post reply on HN