I don't mean this as a criticism, but it's amusing how the Go community is slowly inventing Swift.
- "Protocols" that can be used as both constraints on generic parameters, and existential types
- Operator requirements in protocols
- Associated types
All of the above introduces a huge amount of complexity too, and I imagine trying to retrofit it onto an existing language that does not have generics is going to be an interesting challenge.
To be fair, Swift is on another level, and doesn't strive for Go's rather relentless minimalism. Go, even with these additions, would be a lot smaller than Swift, which was intentionally designed around rich, complex abstractions, including generics and compile-time type constraints, from the start.
Of course, Swift didn't exactly pioneer these concepts. Scala, C# and Haskell also provide compile-time type constraints that are heavily based on generics, and these languages also influenced Swift.
Semantic minimalism, yes. But the produced artifacts are not "minimal". Go is something like IKEA of PLs, making hay with a "minimal" set of elements to play with. But there is only so far you can take plywood.
And above is not a negative critique. It is a good niche to be in. But this effort for Go 2 to move upmarket (in PL land) using the plywood foundation is rather worrisome.
Anecdotally as a mostly full time scala dev, swift has been the easiest "I'm bored this weekend I'll pick up a new language for side projects" I can remember.
- "Protocols" that can be used as both constraints on generic parameters, and existential types
- Operator requirements in protocols
- Associated types
All of the above introduces a huge amount of complexity too, and I imagine trying to retrofit it onto an existing language that does not have generics is going to be an interesting challenge.