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

181–190 of 244 posts

Re: Go Enums Suck

#181

Post by bedobi »

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?

not as many languages as you'd hope unfortunately, but plenty do (see eg other reply you got, there are more still including F# etc etc)

+ other languages get close, eg Kotlin has nullable types (which is a poor substitute) and Result (which is also poor because it's not a true Either)

that said lots of languages these days have libraries that do it (Arrow, Vavr and countless others)

IMO the killer simple language that Go tries and fails to be would be something like a Kotlin+Arrow with heavily reduced syntax and features, eg

no exceptions (use Either or a correct Result type)

no loops (use map, fold etc)

no nulls (use a correct Option/Maybe type)

etc etc

= in such a language, we learn that methods return things, those things will be what they say they are (guaranteed by the compiler), they will tell you what you can do with them, and if a program compiles, you can be pretty damn sure it works as intended

insert "all the languages are broken, I should create a new language" meme here...

Re: Go Enums Suck

#182

Post by mattrick »

neilalexander wrote: post #177
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

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.

Re: Go Enums Suck

#183

Post by pkulak »

smw wrote: post #176
pkulak wrote: post #167

Earlier quoted context omitted.

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

Java 21, and I assume like every scripting language (Ruby, Python, etc). Though I guess with scripting you can't use more than one OS thread (not totally sure). Rust started off with it, and C# tried it too, but there are huge downsides to the model, so it's not like it's perfection incarnate and every other language just can't pull it off.

Re: Go Enums Suck

#184

Post by gleenn »

hardwaregeek wrote: post #45
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…

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…

So the inventors and maintainers of V8 and C are very bad language designers? I don't like either of those languages but those are aome pretty strong words.

Re: Go Enums Suck

#185

Post by hardwaregeek »

gleenn wrote: post #184
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…

So the inventors and maintainers of V8 and C are very bad language designers? I don't like either of those languages but those are aome pretty strong words.

Did any V8 people work on Go? And V8 is an implementation of an existing language, so that fits under "very good software engineer, very bad language designer". As for C, well, it's not a fantastic language. Not to mention, it's been 50 years since C was created, ignoring those 50 years of progress to build essentially C with GC is pretty poor language design.

Re: Go Enums Suck

#186

Post by gregors »

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…

completely agree Elixir is a much better language all around for this type of work

Re: Go Enums Suck

#187

Post by gregors »

LispSporks22 wrote: post #163
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…

> Why do you unwind the stack? Something terrible happened? Definitely not, Definitely do. In Go we just have to emulate it, badly, by manually writing code to forward the error up the stack so you can finally top-level print “error bad thing happen” or maybe some unholy stringification of wrapped errors possibly collected along the way.

I still can't understand how anyone designing a language can defend self-rolled stack traces as a good thing.

Re: Go Enums Suck

#188

Post by beautron »

I love Go's lightweight, somewhat implicit style of doing enums.

You just declare an int type, and then a list of constants of that type.

People are complaining about 'iota' here, but I think it's slick and great. It combines so nicely with eliding types and values from subsequent const declarations:

  type MyEnum int

  const (
      Value1 MyEnum = iota
      Value2
      Value3
      ...
  )
Nice and simple. Most of the syntax is just the enum value identifiers. And it works well for bit flags too:

  type MyFlags int

  const (
      Flag1 MyFlags = 1
Most of the above syntax isn't specific to enums (so you're already getting a lot of other things from it). The only enum-specific syntax is iota and the eliding type/value rule.

People seem to want their languages to have all sorts of guardrails, but I find many of these cumbersome. Go gives me the one enum guardrail I care about: The enums are different types, so I can't use a MyEnum as a MyFlag, or vice versa.

I've worked on giant Go codebases, with Go-style enums all over the place, and the lack of compiler-enforced exhaustive enum switches just hasn't been a problem. And it's nice to be able to use non-exhaustive switches, when you want them. Go is simple and flexible here.

The article criticizes Go incorrectly with statements such as these:

> This also means any function that uses these or a struct that contains these can also just take an int value.

> Anywhere that accepts an Operation Enum type will just as happily accept an int.

This is just not true. Here's an example you can run: https://go.dev/play/p/8VGufuxgK6b

The above example tries to assign an int variable to a MyEnum variable, and gives the following error: "cannot use myInt (variable of type int) as MyEnum value in variable declaration"

This error directly contradicts what is claimed in the article. Perhaps they mean that MyEnum will accept an integer literal, in which case I would argue that a guardrail here is silly, because again the problem just doesn't really come up in practice. Regardless, the author is not being very precise or clear in their thinking.

Re: Go Enums Suck

#189

Post by da39a3ee »

the__alchemist wrote: post #139
jerf wrote: post #132

Earlier quoted context omitted.

OK, so now you are advocating for erasing the distinctions. Why? Why is it so important that they be seen as the same thing to you? What benefit is gained from it? What benefit is gained from blending together a data structure that is fixed bit size from a family of data structures of variable size, a fairly fundamental difference? What benefit is gained from failing to consider the fundamentally different uses they…

I'm not advocating for anything; I love Rust Enums and use whatever is close to them in other languages, which is usually better than the alternative of matching strings or similar (A convention in Python). When I hear "These aren't really enums", my first reaction is to dive in and do research. (I'd been down this road before, probably after a similar HN comment...), but I haven't found usable or practical conclusio…

Think about the way each alternative branch of a Rust "enum" can model arbitrarily nested data. That's completely different from the things in Go and Python that are called "enums".

Re: Go Enums Suck

#190

Post by [deleted] »

pkulak wrote: post #80
BugsJustFindMe wrote: post #4

> Go doesn’t technially have Enums and it is a missing feature in my book but there is a Go idiomatic way to achieve roughly the same thing. Oh, so it's a lot like Python then. > This is fine however it is nothing but an integer under the covers this means what we actually have is: Oh, so it's a lot like C++ then. > But what you notice here is we have no string representation of these Enums so we have to build that o…

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.

[deleted]
Post reply on HN