The trouble is that Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing, so by using slightly different syntax, iota, Go avoided the whole confusion of users thinking that enums would behave like sum types instead of actual enums.
Is your attempt at making a point 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.
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
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
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.
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
So is nil. Care to make the same argument?
There is a stronger case to be made for the other two. Calling GOPATH a design mistake is a stretch as it was perfectly suited to use within Google, but it didn't fit the typical solo developer's environment. Lack of generics made writing certain types of code difficult. You could be convincing in suggesting that Go did end up being used less than it otherwise would have because of those choices.
iota? It's just a construct that generates numbers (an enum). How does that kneecap anything? If it really bothers you, you can manually number the values by hand instead. Why would anyone reject a language because it allows you to optionally choose to have the compiler assign numbers automatically instead of forcing you to do it manually? The answer is nobody. In fact, most popular languages have something equivalent to iota.
Thus “go borrowed it from C, therefore it can’t have been a mistake” is a pretty lame take. The whole point of a new language is to make improvements on what’s out there already. Go missed an opportunity to fix one of C’s most notorious mistakes. So yes, they kneecapped themselves by forcing all of the users of Go to continue dealing with this well-known footgun.
Does it mean Go isn’t popular? Of course not. C was popular. PHP was popular. JavaScript is popular. Go is popular. This is always in spite of their faults. But Go could have been better.
> Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing
Of course the social landscape depends on people actually using it. None of the people who weren’t using Rust at the time were magically confused about enums and sum types by the mere existence of some new and experimental language.
Rust barely existed at the time Go was first being developed. And given the history of Go and the notoriety of its core team for flatly ignoring prior work in programming languages, it’s extremely unlikely that Pike et al gave more than a cursory glance to what nascent Rust was doing at the time.
But even if they had, to suggest that they intentionally replicated a dumb thing from C but gave it a different name to avoid users being confused by a different thing from a language that roughly nobody knew about at the time is bananas.