> This idea proves to be surprisingly powerful when it comes to expressing constraints on generic functions and types.
Disagree. IMHO, this idea is the root cause of why Go generics is so complicate but also restrictive at the same time. And it introduces significant challenges in implementation and design: https://go101.org/generics/888-the-status-quo-of-go-custom-g...
If I'm being honest, the magic of Go was lost when generics were introduced. It now feels akin to Java, which I guess was inevitable and for anyone to really take it seriously maybe it needed to get here. But I am not a fan of generics. While that level of abstraction and composability is clever, it also lends itself to more complexity and systems that can be harder to concretely understand. Just an opinion that I know many will not agree with but I come from the systems side rather than pure software engineering. It's probably ironic considering go-micro leans heavily on interfaces for abstraction but in that there are many hard learned lessons.
I was so excited when generics were going to release, and, tbh, I've barely used them. It's made some code easier to express correctly in the type system in rare cases.
I don't think I'd agree it's made the language "Java-like". That sounds like more of an indictment of the author of the code you're reviewing ;)
Horrorshow. Longterm Go user and open source maintainer here.. looking at this code makes me want to puke. The whole thing is a crime against semantics. I thought the whole point was to do generics when they could do them well, right? This is unwell..
> At this point, you might feel pretty overwhelmed. This is rather complicated and it seems unreasonable to expect every Go programmer to understand what is going on in this function signature. We also had to introduce yet more names into our API. When people cautioned against adding generics to Go in the first place, this is one of the things they were worried about.
One of the key benefits of Go, at least for me, was not having to think about any of this at all ever.
Whenever I touch generics, I find myself engrossed in the possibility of cleverly implementing something. Hours will pass as I try to solve the fun puzzle of how to do the thing using generics, rather than just solve the problem at hand.
I find C++ templates simpler than Go generics. With C++, you can at-least get to a design solution. With Go generics: oops this is not possible, oops that is not possible - all because of strange language limitations.
Go's Generics are a crippled implementation - they don't really deserve the feature title of 'generics'. (Its like saying you support regex, but don't support groups and repeat operators and you can only match them to special types of strings.)
If Go generics support typeclasses, things will be much better now. At least custom generics and built-in generics will be unified harmoniously. Now, the manners of type argument passing with the built-in `new` and `make` function and custom generic functions are different. The inconsistency increases the load of cognition burden in Go programming.
It is pity that Go generics designer never expressed the intention to unify custom generics and built-in generics.
When I first learned about Go I thought the idea was to have a simple C-like language with a frozen feature set. A language that would look the same today and ten years from now. And I thought that boringness was a wonderful feature, actually.
If they're going to be adding features to the language, albeit at a slower pace than Java/C#, what's the point really? On a long enough timeline Go is going to be indistinguishable from these more feature-rich languages.
> A language that would look the same today and ten years from now.
You can still write Go 1.11 code and compile it with the Go 1.24 compiler. If you specify 1.11 in your go.mod it compiles your code with the 1.11 syntax.
It was also promoted as a language that prioritizes explicitness. But just look at the changes made in Go 1.22 (3-clause for-loop semantic change, [1]) and 1.23 (iterators, [2]). Magic implicitness was introduced in the two versions.
Even worse, it was also promoted to keep backboard-compatibility seriously. But Go 1.22 broke the backward-compatibility so badly ([3] [1]). Despite this, the Go 1.22 release notes still claims "As always, the release maintains the Go 1 promise of compatibility".
Preaching to the choir here, but this is why a lot of the Go community was against generics.
Especially in the era of AI assistants, the downside of writing out explicit types and repetition matters very little, while the upside of avoiding all this complexity is unmeasurable.
>There is an idea that is not obvious until you hear about it for the first time: as interfaces are types themselves, they too can have type parameters
Not obvious???? Go language designers and programmers are living in another world
18 comments
[ 2.8 ms ] story [ 48.2 ms ] threadDisagree. IMHO, this idea is the root cause of why Go generics is so complicate but also restrictive at the same time. And it introduces significant challenges in implementation and design: https://go101.org/generics/888-the-status-quo-of-go-custom-g...
Are there any real packages out there using these techniques?
I don't think I'd agree it's made the language "Java-like". That sounds like more of an indictment of the author of the code you're reviewing ;)
Welcome to civilization, golang. Were there ever any language developers with more hybris?
One of the key benefits of Go, at least for me, was not having to think about any of this at all ever.
Whenever I touch generics, I find myself engrossed in the possibility of cleverly implementing something. Hours will pass as I try to solve the fun puzzle of how to do the thing using generics, rather than just solve the problem at hand.
Go's Generics are a crippled implementation - they don't really deserve the feature title of 'generics'. (Its like saying you support regex, but don't support groups and repeat operators and you can only match them to special types of strings.)
It is pity that Go generics designer never expressed the intention to unify custom generics and built-in generics.
If they're going to be adding features to the language, albeit at a slower pace than Java/C#, what's the point really? On a long enough timeline Go is going to be indistinguishable from these more feature-rich languages.
You can still write Go 1.11 code and compile it with the Go 1.24 compiler. If you specify 1.11 in your go.mod it compiles your code with the 1.11 syntax.
What a shitshow. Seems like Go's designers didn't know about interfaces, generics, and iterators when decided to make a language...
Even worse, it was also promoted to keep backboard-compatibility seriously. But Go 1.22 broke the backward-compatibility so badly ([3] [1]). Despite this, the Go 1.22 release notes still claims "As always, the release maintains the Go 1 promise of compatibility".
[1]: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
[2]: https://go101.org/blog/2025-03-15-some-facts-about-iterators...
[3]: https://go101.org/bugs/go-build-directive-not-work.html
And the change makers even have no interests to fix the problems caused by the changes:
* https://github.com/golang/go/issues/66070#issuecomment-19816...
* https://github.com/golang/go/issues/71830
* https://github.com/spq/pkappa2/issues/238
* https://github.com/golang/go/issues/66388
* https://github.com/golang/go/issues/71685
Especially in the era of AI assistants, the downside of writing out explicit types and repetition matters very little, while the upside of avoiding all this complexity is unmeasurable.
Not obvious???? Go language designers and programmers are living in another world