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

151–160 of 244 posts

Re: Go Enums Suck

#151

Post by llmblockchain »

zarldev wrote: post #149
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.

Yes. Your DSL is JSON in this case,

{ "enums": [ { "package": "cmd", "type": "operation", "values": [ "Escalated", "Archived", "Deleted", "Completed" ] } ] }

My point was the "Go" way to do this isn't parsing a custom format (like your JSON), but it's to use go generate.

Re: Go Enums Suck

#152

Post by grumpyprole »

randomdata wrote: post #141
grumpyprole wrote: post #120

Earlier quoted context omitted.

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.

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'

Re: Go Enums Suck

#153

Post by zarldev »

llmblockchain wrote: post #151
zarldev wrote: post #149

Earlier quoted context omitted.

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.

Yes. Your DSL is JSON in this case, { "enums": [ { "package": "cmd", "type": "operation", "values": [ "Escalated", "Archived", "Deleted", "Completed" ] } ] } My point was the "Go" way to do this isn't parsing a custom format (like your JSON), but it's to use go generate.

But all go generate does is run a binary like stringer? This can be used in go generate.

Re: Go Enums Suck

#154

Post by trealira »

adamrezich wrote: post #24
randomdata wrote: post #11

Earlier quoted context omitted.

> Go has constants That's literally what enums are: A set of named constants. You might be thinking of what is traditionally known as sum types, which some people have recently started calling enums[1]. Indeed, Go does not have sum types. [1] Presumably because of Rust using the wrong term when specifying its sum types

is there any further information on why Rust and other recent languages have started using `enum` to refer to sum types? I don't use Rust or TypeScript (edit: apparently TS doesn't have this, my memory is bad) or any of those languages and it's been very strange to see this redefinition occur

Maybe to appeal to C and C++ developers. Rust makes its syntax superficially similar to C/C++ syntax in many other ways: pointer/reference syntax, declaration of "struct" types, generic types using , curly brace block structure, and the naming conventions enforced by their lints. To be fair, many of these traits of C and C++ are also copied by other programming languages (e.g. curly braces). But they could have gone in a different direction and had pointer and record syntax more like Pascal, or made a syntax more like OCaml, Standard ML, or Haskell.

Re: Go Enums Suck

#155

Post by bedobi »

yhavr wrote: post #138
bedobi wrote: post #117

Earlier quoted context omitted.

You're right. Go is not simple, it is idiotically designed to deliberately exclude common sense features that ironically makes it less simple and more error prone to code in and read Go. Other languages are objectively better than Go for every imaginable use case. Rust is better for embedded. Kotlin is better for back end. I could go on. The creator of Go is very open and candid that he thinks his target audience, Go…

> 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 like Option, List etc and are trivial to learn in a day for people who aren't familiar with them)

+ not making the compiler distinguish between null and non-nully values (as eg Kotlin, Rust and Haskell does) in itself as well is inexcusable for a modern language

Re: Go Enums Suck

#156

Post by avgcorrection »

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…

It’s funny to emphasize the vibes of a language contra other ones when you’re supposed to be on the supposedly pragmatic side. Haskell and Rust are popular on “message boards”? Better not mention them among my peers and risk my blue collar street cred.

But it’s a red herring in any case since enum types are such a basic programming language feature. No need to evoke the Cool Kids languages at all.

Re: Go Enums Suck

#157

Post by avgcorrection »

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…

“Enumeration” according to a handy dictionary: “the act or process of making or stating a list of things one after another”

I am—for some reason—reminded of philosophers who go looking for metaphysical problems, disputes, etc. where there aren’t any.[1]

https://en.wikipedia.org/wiki/Quietism_(philosophy)

Re: Go Enums Suck

#158

Post by avgcorrection »

mseepgood wrote: post #92
glenjamin wrote: post #76

Earlier quoted context omitted.

> Is this a real problem? If there's a function signature that accepts `Operation`, the caller must explicitly cast the `int` to `Operation`. At that point, it's the caller's own fault. You would think that, but that isn't always the case: https://play.golang.com/p/Ze3pfNEVTVs It's very easy to create an enum value that isn't actually in the defined range

Can you explain the thought process of a developer when they write 'performOperation(2)'? What do they believe '2' signifies in this context? I struggle to believe that this could occur by accident.

You struggle to imagine a programmer passing a value of the wrong type to a function?

Re: Go Enums Suck

#159

Post by sydbarrett74 »

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

Ada rocks. It's just about the most underappreciated language ever.

Re: Go Enums Suck

#160

Post by scosman »

Jtsummers wrote: post #93
scosman wrote: post #52

Earlier quoted context omitted.

Not a great take. The go team made a lot of decisions that weren't mainstream at the time, and nailed them. Fast builds, native binaries, language simplicity, new concurrent primitives, interface model, defer, no build flags, package system. Yeah it has evolved a bit since, but keeping the language simple is a worthwhile goal, so they didn't make rapid changes. It was intentional and thoughtful. If you want lots of l…

> new concurrent primitives You could make a case that concurrency primitives weren't mainstream in programming languages at the time. But there's not a strong case for saying that Go introduced new concurrency primitives unless you just ignore the history of programming and programming languages. Nothing in Go's concurrency model was new. Not quite mainstream, sure. But not new. [EDIT: By primitives I take you to me…

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 in one go, and still make something successful.
Post reply on HN