Hacker News new | ask | show | jobs
by coldtea 844 days ago
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.

4 comments

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.

>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 would be against go's identity.

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

Why use ints in the first place if what you really want is strings?
Integers are far faster, smaller, and golang is strongly typed. Once you're past the serialization phase, strings have many disadvantages.
> rigid and encompassing

Rigid makes it sound bad. I would suggest "reliable" instead.

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

Having an actual set type is much better than having to manually fiddle with bitwise operations.
...also:

* no null safety

* working with errors

* poor type system