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

101–110 of 244 posts

Re: Go Enums Suck

#101

Post by klysm »

mseepgood wrote: post #65
klysm wrote: post #15

Earlier quoted context omitted.

I think boneheaded is a good way to describe the evolution of go. It seems like the original authors were convinced most of the complexity of modern languages was unjustified and have slowly proven themselves incorrect over the years

> convinced most of the complexity of modern languages was unjustified You don't think that most of the complexity of modern languages is unjustified?

I think most modern languages have complexity in the wrong areas. The type systems are not complex enough to capture the things I want algebraic data types with exhaustiveness guarantees).

Re: Go Enums Suck

#102

Post by DinaCoder99 »

Steltek wrote: post #32
coldtea wrote: post #10

Go's iota is probably one of the worst ideas in all programming languages. Not a full typesafe enum type, the same clunky "enums" (assigned constants) available in C, but they bother to implement an auto-incremented counter. So you can't depend on the enum for exhaustiveness warnings e.g. on switch statements, type checking, or correctness, but you do get a useless numeric association autogenerated with iota - so tha…

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?

Re: Go Enums Suck

#103

Post by BugsJustFindMe »

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

Python does have enums in its standard library https://docs.python.org/3/library/enum.html

Heh. Python's enums are not real types, they're just funny classes, so you still have to do dumb things like assign an internal value (commonly a dumb int) and were (and probably still are) wildly deficient in many other commonly-desired ways for a very long time. A bunch of things covered in this blog post (like StrEnum and EnumCheck) weren't added until pretty recently.

Re: Go Enums Suck

#104

Post by mseepgood »

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.

Wirth regretted it later and didn't add it to Oberon. Quote from "From Modula to Oberon":

"Enumeration types appear to be a simple enough feature to be uncontroversial. However, they defy extensibility over module boundaries. Either a facility to extend given enumeration types has to be introduced, or they have to be dropped. A reason in favour of the latter, radical solution was the observation that in a growing number of programs the indiscriminate use of enumerations (and subranges) had led to a type explosion that contributed not to program clarity but rather to verbosity. In connection with import and export, enumerations give rise to the exceptional rule that the import of a type identifier also causes the (automatic) import of all associated constant identifiers. This exceptional rule defies conceptual simplicity and causes unpleasant problems for the implementor."

Re: Go Enums Suck

#105

Post by [deleted] »

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…

[deleted]

Re: Go Enums Suck

#106

Post by klysm »

scosman wrote: post #52
klysm wrote: post #15

Earlier quoted context omitted.

I think boneheaded is a good way to describe the evolution of go. It seems like the original authors were convinced most of the complexity of modern languages was unjustified and have slowly proven themselves incorrect over the years

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…

I totally agree that go nailed the head on a lot of things, including the list you provided (minus package system). I’m not convinced the evolution was intentional though from the start. From my memory the _attitude_ of the go ecosystem was that generics were not worth the complexity (for example). I don’t have any concrete evidence of that, it’s just the vibe I got from talking to folks about it.

I also have great distaste for error handling in go but that’s a distinct argument to have.

Re: Go Enums Suck

#107

Post by [deleted] »

jimbob45 wrote: post #39
downWidOutaFite wrote: post #30

Earlier quoted context omitted.

That's a minor implementation detail that devs almost never have to think about.

You'll run into it with generic arrays[0] in Java which are reasonably common. [0] https://www.baeldung.com/java-generic-array

[deleted]

Re: Go Enums Suck

#108

Post by t0astbread »

What I like about Go is not the language itself (I'm not a language designer but I dislike a lot of choices that Go makes) but the entire culture around it of doing things the idiomatic way and moving on. I'm someone who, if you give them a tool that's flexible, will spend time optimizing it. And I'm already busy optimizing other stuff so it's nice to have something constant to build upon.

Oh and you don't have to use large power-hungry IDEs that don't integrate with any sort of config management to get a decent experience! (/hj)

If I ever learn Haskell it's over for y'all though.

(Agree with OP btw, using codegen to get the enums I want is a workable remedy for Go's lack of enums.)

Re: Go Enums Suck

#109

Post by samatman »

randomdata wrote: post #6
the__alchemist wrote: post #3

Go and Python have OK enums. I will use them, but they could be simpler/more expressive. This begs the question: Is there an obstacle to releasing better enums in the next Python and Go versions? If the concern is about breaking backwards compatibility, I would be OK with a new type. Is it a culture issue, ie that Python and Go programmers don't use enums much? (Chick + egg here) Rust's enums are great. No "auto" boi…

> Rust's enums are great. Rust doesn't have enums. It has sum types – that for some reason it arbitrarily decided to call enums. Sum types are great. There is a good case to be made that Go would benefit from the addition of sum types. But until that day there isn't much more you can do with enums. That's all enums are – a set of named constants.

Rust's enums are entirely unlike C enums, and reasonably similar to Java enums.

Not the first time a word has been used for several nearly-unrelated concepts, and it won't be the last.

Re: Go Enums Suck

#110

Post by layer8 »

sgift wrote: post #67
Zambyte wrote: post #20

Earlier quoted context omitted.

In what sense? Because they only apply to non-primitive types?

To allow backward compatibility Java introduced Generics with type erasure, which in short means they only exist at compile-time, not at runtime (there are some hacks around that, which various devs have used with great success to still get the information). That is another reason to just start with Generics from the beginning if you design a new language, so you won't have compatibility problems when you introduce t…

IIRC Arthur Van Hoff, one of the original Java developers, actually advocated for the inclusion of generics in the initial version, but it was dropped due to time constraints. It’s one of those features that a statically types language will always regret to not include from the beginning.
Post reply on HN