5 ms·

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) availab

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 that you can lose the association if you re-order your enum values that you have serialized earlier and want to reload in the future.

Steltek 3y ago
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, etc.
- coldtea 3y ago
  >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...
  - preommr 3y ago
    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 would be against go's identity.
    - deleted 3y ago
      [deleted]
    - richbell 3y ago
      > 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. I can't tell if this is sarcasm. If it isn't, I don't see how what you've mentioned is minimalistic or how adding an option type would be against Go's identity.
    - deleted 3y ago
      [deleted]
- DinaCoder99 3y ago
  Why use ints in the first place if what you really want is strings?
  - Steltek 3y ago
    Integers are far faster, smaller, and golang is strongly typed. Once you're past the serialization phase, strings have many disadvantages.
- IshKebab 3y ago
  > rigid and encompassing Rigid makes it sound bad. I would suggest "reliable" instead.
mirekrusin 3y ago
...also: * no null safety * working with errors * poor type system
mseepgood 3y ago
> Go's iota is probably one of the worst ideas in all programming languages. iota is a great idea, especially if you have to define bit mask constants, e.g. 1 << iota. I wish other languages (yes, also those with enums) had it as well.
- xigoi 3y ago
  Having an actual set type is much better than having to manually fiddle with bitwise operations.
baranul 3y ago
This is well said. I understand wanting to keep the language smallish and simple, but enums is such a basic and well known feature, it's almost asking for trouble or dissatisfaction to not fully implement it.

Steltek 3y ago

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

coldtea 3y ago
>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...
- preommr 3y ago
  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 would be against go's identity.
  - deleted 3y ago
    [deleted]
  - richbell 3y ago
    > 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. I can't tell if this is sarcasm. If it isn't, I don't see how what you've mentioned is minimalistic or how adding an option type would be against Go's identity.
  - deleted 3y ago
    [deleted]
DinaCoder99 3y ago
Why use ints in the first place if what you really want is strings?
- Steltek 3y ago
  Integers are far faster, smaller, and golang is strongly typed. Once you're past the serialization phase, strings have many disadvantages.
IshKebab 3y ago
> rigid and encompassing Rigid makes it sound bad. I would suggest "reliable" instead.

mirekrusin 3y ago

...also: * no null safety * working with errors * poor type system

mseepgood 3y ago

> Go's iota is probably one of the worst ideas in all programming languages. iota is a great idea, especially if you have to define bit mask constants, e.g. 1 << iota. I wish other languages (yes, also those with enums) had it as well.

xigoi 3y ago
Having an actual set type is much better than having to manually fiddle with bitwise operations.

baranul 3y ago

This is well said. I understand wanting to keep the language smallish and simple, but enums is such a basic and well known feature, it's almost asking for trouble or dissatisfaction to not fully implement it.