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

171–180 of 244 posts

Re: Go Enums Suck

#171

Post by sgift »

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.

As someone who works with Java all the time I'm the first to admit that something like TypeToken in GSON or comparable things in other libraries is not the greatest of things. I've also more than once wished I could to if(xy instanceof List), which you cannot do in Java. Can you work around it? Sure. Do I understand why Java has it? Yes. But "minor" .. no, it's not so minor in my experience.

Re: Go Enums Suck

#172

Post by lantastic »

kleton wrote: post #56

I use this one https://github.com/abice/go-enum

I like the "go generate" approach to integrate such tools. I used a different (but identically named) go-enum tool [0], which accepts the go type and generates implementations for a bunch of interfaces. The neat thing is that the starting point is the "idiomatic" go enum definition, rather than description via a separate DSL:

  //go:generate go-enum -type=State
  type State int
  const (
    Unknown State = 0
    Disconnected = 1
    Connected = 2
  )
which then generates a separate file with implementations such as:

  func (i State) MarshalJSON() ([]byte, error) { ...
[0] https://pkg.go.dev/github.com/searKing/golang/tools/go-enum#...

Re: Go Enums Suck

#173

Post by uticus »

bedobi wrote: post #155
yhavr wrote: post #138

Earlier quoted context omitted.

> sane error handling? Golang _has_ sane error handling. It just considers errors a normal and expected situation. When you perform a http request, and the result is successful you expect the result to be assigned a variable, right? Then why would you expect non-successful outcome to be returned in a different way? Why is it different? Why do you unwind the stack? Something terrible happened? Definitely not, it's as…

100% agree, and Go gets oh so close But the correct and only sane way to do this is Either that you can then pass on, map over both or either of the two, flatMap to chain with other Eithers, fold into a single thing etc etc. Not endless sprinkling of if err != nil { log.Fatal(err) } everywhere (and no, those operations are not obscure, esoteric or difficult to learn or understand - they're the same for other types li…

What language typically returns the `Either` you refer to here? I get (and love) the idea but have never seen it in official documentation (sure I could go off the beaten path and implement in my language of choice).

Also, did you come up with this on your own, or were you exposed to it?

Re: Go Enums Suck

#174

Post by grumpyprole »

randomdata wrote: post #168
grumpyprole wrote: post #152

Earlier quoted context omitted.

It has a lot to do with enums, especially if you are claiming statically typed enums. When defining a type, more often than not, we want to define the values that make up the set. For example, 'type boolean = true | false'

> we want to define the values that make up the set. For example, 'type boolean = true | false' Sure, or, more relevant, `type monthOrdinal = 1-12` or `type email = {string}@{string}`. Any advanced type system will allow for that, of course, but Go does not. It does not even pretend to claim to be an advanced language. It has, quite explicitly, chosen to not be. Yes, you are right that if Go had value constraints the…

> You're confusing unrelated features

Actually I think you are. For example, almost all statically typed languages since Pascal do not have value constraints but support typed enums as closed sets. There's no advanced type system needed - no need to define enums as integers and then put additional constraints in the type system to try and restrict this. There is also no need to model enums as integers in the type system in order to use integers as a runtime representation.

Re: Go Enums Suck

#176

Post by smw »

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…

I find go distasteful, but are there really many other languages with an m:n threading model? Only other popular one I can think of is Erlang/Elixir.

Re: Go Enums Suck

#177

Post by neilalexander »

015a wrote: post #127

`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 in…

> 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

Re: Go Enums Suck

#178

Post by MarkSweep »

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…

So I guess you have a point that since Go does not even have enum’s as a formal concept, they can’t suck. But this presumes that the only context where you can criticize Go is the context that only contain’s concepts expressible in Go. This is basically saying “Go does not have enums, therefore it cannot be criticized for lacking enums”.

In the wider context of programming languages, enum is fairly well defined concept. Features like being able to convert a value to a string and do exhaustive checking on switch statements are widely implemented. The iota feature in Go is clearly imitating C’s enum keyword. It is fair to compare Go’s built-in ability to declare an enum-like type against other language’s ability to declare the concept.

To be clear, I’m not saying every language has to have every feature. I’m just saying the lack of a feature in a language is not a sufficient reason to excuse its lack.

Re: Go Enums Suck

#179

Post by oasisaimlessly »

uticus wrote: post #173
bedobi wrote: post #155

Earlier quoted context omitted.

100% agree, and Go gets oh so close But the correct and only sane way to do this is Either that you can then pass on, map over both or either of the two, flatMap to chain with other Eithers, fold into a single thing etc etc. Not endless sprinkling of if err != nil { log.Fatal(err) } everywhere (and no, those operations are not obscure, esoteric or difficult to learn or understand - they're the same for other types li…

What language typically returns the `Either ` you refer to here? I get (and love) the idea but have never seen it in official documentation (sure I could go off the beaten path and implement in my language of choice). Also, did you come up with this on your own, or were you exposed to it?

* Rust: https://doc.rust-lang.org/std/result/

* Haskell: https://hackage.haskell.org/package/base-4.19.1.0/docs/Data-...

* C++: https://en.cppreference.com/w/cpp/utility/expected/value

Re: Go Enums Suck

#180

Post by randomdata »

grumpyprole wrote: post #174
randomdata wrote: post #168

Earlier quoted context omitted.

> we want to define the values that make up the set. For example, 'type boolean = true | false' Sure, or, more relevant, `type monthOrdinal = 1-12` or `type email = {string}@{string}`. Any advanced type system will allow for that, of course, but Go does not. It does not even pretend to claim to be an advanced language. It has, quite explicitly, chosen to not be. Yes, you are right that if Go had value constraints the…

> You're confusing unrelated features Actually I think you are. For example, almost all statically typed languages since Pascal do not have value constraints but support typed enums as closed sets. There's no advanced type system needed - no need to define enums as integers and then put additional constraints in the type system to try and restrict this. There is also no need to model enums as integers in the type sys…

You can't have closed enums without value constraints. Yes, some languages have been lazy and provided value constraints only for enum types.

Which is an interesting choice: Give a noose for developers to hang themselves with for every single other type other than enums – the types they are going to use most often – and not think twice, but then go full on helicopter parent when using enums – the one type that isn't particularly interesting.

It's a neat parlour trick, don't get me wrong, but I guess that's why almost all of the popular statically typed languages since Pascal (C, C++[1], Typescript[2], etc.) didn't bother with closed enums. They put their time into features that actually mattered to developers instead.

[1] Added later in life, granted.

[2] Ironically, does support value constraints except in the case of using enum.

Post reply on HN