Comment by maccard

3 hours ago

> Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript.

iota is a massive kneecap _because_ it's semantically identical to enum in C and Typescript.

> Is your argument actually that not having sum types is the massive flaw? Sum types are a useful construct, to be sure, but there are plenty of good languages without them. That's more on the design quirk end, realistically.

In a dream world sure we'd have full blown sum types (and that would give a result type which would also solve a lot of the nil-interface-combined-with-error-handling issues that I've ran into when working with go), but I can forgive that. The problem is this - https://www.zarl.dev/posts/enums

1 comment

maccard

9rx 37 minutes ago

> The problem is this - https://www.zarl.dev/posts/enums

The only case I see made in there is that it doesn't like how Go implicitly converts consts. While that may be a reasonable criticism, it doesn't have anything to do with iota. It is related to the type system and applies in general. Consider the same problem exhibited here:

    type Email string
    func Send(email Email)
    func() { Send("invalid") } // Converted string const does not satisfy Email type expectations

Perhaps you accidentally offered the wrong link?

It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language". Being able to pass arbitrary values is perfectly in line with a dynamically-typed language. Realistically, the type system in Go is there to give the compiler optimization hints, not to offer type safety. Go was targeted at those wanting to use Python, without the programs being painfully slow to run. How much of a kneecap is implicit type conversion, really, when it is already in line with what the target audience is accustomed to? It is a quirk at best.