> 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

▲ 9rx 7 hours ago | parent [-]

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

▲

maccard 6 hours ago | parent [-]

> It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language".

If I google this quote a comment from you comes up here on this exact topic, where you seem to have completely missed the point there too. If I link to the docs [0], the full quote is "It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. " So it is a statically typed language first and foremost. If you want to rehash the discussion and tell people that a flawed type system that people have been asking for a solution to for close to a decade [1] you can just re-read the last time the arugments were made as I don't think I'm going to make any headway there.

[0] https://go.dev/doc/ [1] https://github.com/golang/go/issues/19814

	▲	9rx 6 hours ago \| parent [-]
		> So it is a statically typed language first and foremost. Right, because that is primarily how it makes things fast. Python is slow largely because it spends an inordinate amount of time trying to figure out what things are. Go knows what things are at compile time because the static type system tells it what things are and thus doesn't have to waste runtime compute on figuring out what things are, aside from when you use the reflect package, like Python does. That was its value-add — that it is kind of like Python, but faster. We already went over this... > If I link to the docs [0] I said original announcement, so I'm not sure why you wouldn't look there? Trying to be obtuse on purpose? Regardless, performance was indeed considered more important than being dynamically-typed. After all, if performance wasn't a concern then you'd just use Python. Go exists only because it was solving a problem that wasn't already solved. Slow Python was already solved. Type safety was already solved. It didn't need to go into those territories.