Pascal in its original 1970's design, type myEnum = (value1, value2, value3, value4) Naturally that is too advanced and slows compile times.
> Naturally that is too advanced and slows compile times.
Sarcasm ?
Go Enums Suck
81–90 of 244 posts
Re: Go Enums Suck
#82The root cause is wanting to support fixed-size array types in structs, which means nothing can require initialization and everything needs a zero value. The caller can just modify every field directly.
This is sort of like how network protocols can’t statically guarantee enums are valid either. When sending bits over the wire, you can send any bits you like. There can be “values reserved for future use,” but to deny their use, you need a runtime check.
A similar solution works in Go. A runtime check in a constructor function will fix it. The enum’s value would need to be returned as an unexported field in a struct, which is the only way to guarantee that it’s not writable, except by copying it from another valid value.
I don’t see a particular reason why Go couldn’t make this easier.
Re: Go Enums Suck
#83Earlier quoted context omitted.
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
Typescript has actual enums. They behave just like Go's (for better or worse). It's not clear why Rust got confused.
yep, sorry about that, I misremembered TypeScript as having the same "kind of enums" as Rust.
Re: Go Enums Suck
#84It's actually the coolest thing about Go enums, that they just it – enums.
Developers with a background in other languages assume all enums' use cases need string representation. Well, no. They are needed sometimes, but not always.
The same with the ability to pass int to the enum. Author says:
> Anywhere that accepts an Operation Enum type will just as happily accept an int.
Well, this is simply not true. [1] You'll have to cast your int into your enum, which is totally fine if it's your intent. Granted, there are plenty of valid cases where you need validated input, especially for the public libraries. But hey, not every code is a publicly facing library, and not all need this validation. Why spend CPU and memory on something that probably won't be needed, and that can be implemented with the existing language primitives?
In the end, the author did a great job of solving his own requirements around enums and even wrote a code generator that helps him generate this for millions of enum types per second. :)
Re: Go Enums Suck
#85I 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…
This is the "you're holding it wrong" of linguistic arguments.
Re: Go Enums Suck
#86Earlier 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…
[deleted]
Re: Go Enums Suck
#87> 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.
More efficient than a scripting language, less performant than a systems language. I really like it for anything network-related.
Re: Go Enums Suck
#88I 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…
I'm working on an LLM project in Go and the term "context" is overloaded to the hilt--I use it to refer to the LLM context as well as Go's `context.Context` which I'm using all over the place. It's made worse since the most natural plural of context is... context. My solution is to use `ctx` for Go context, `contexts` for arrays of LLM context structs, and `contextPart` for individual context structs.
"model" is another one like that since I'm using it to refer to both data models and ML models. And "prompt" since it can be an LLM prompt or a terminal prompt for the user (this is a CLI tool).
Differentiating all these overlapping terms in ways that aren't super confusing is definitely a challenge.
Re: Go Enums Suck
#89> 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.
It's all of the ergonomics of C combined with the bare metal performance of a garbage collector.
Re: Go Enums Suck
#90Earlier quoted context omitted.
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
I think it might be due to the O'Caml influence on early Rust. They call them enums there[0]. [0] https://www.ocamlwiki.com/index.php?title=Enums_in_OCaml
They are called variants in OCaml (and inductive data types in Roqc).
But way more important: this OCaml wiki is an AI generated mess full of, well, bullshit. https://discuss.ocaml.org/t/whats-up-with-ocamlwiki/13605