Related earlier discussions:<p>- <a href="https://news.ycombinator.com/item?id=20576845" rel="nofollow">https://news.ycombinator.com/item?id=20576845</a> (2019 draft)<p>- <a href="https://news.ycombinator.com/item?id=20541079" rel="nofollow">https://news.ycombinator.com/item?id=20541079</a> (also 2019 draft)<p>- <a href="https://news.ycombinator.com/item?id=23543131" rel="nofollow">https://news.ycombinator.com/item?id=23543131</a> (2020 draft, i.e. the base version of the current draft)
We have a very large Go codebase here at Stream and not having generics is just not really as big of an issue as you think it is. There are plenty of work arounds if you get used to not having generics in the language. The fast compile times of Go are amazing. I was doing some Kotlin a few weeks ago and the difference is crazy. Go: Install deps, compile everything done in 5s. Doing the same in Kotlin, laptop freezes, android studio freeze, time to get a coffee :)<p>That being said it would be really nice to have some reusable map type structures that handle GC better than the default maps. Fingers crossed.
Two more levels of blogs down, the actual proposal.[1] Definition:<p><pre><code> // Print has a type parameter T and has a single (non-type)
// parameter s which is a slice of that type parameter.
func Print[T any](s []T) { ... }
</code></pre>
Call:<p><pre><code> Print[int]([]int{1, 2, 3})
</code></pre>
Above, "any" is really just a synonym for "interface{}". You can have more restrictive type constraints on parameterized types by specifying other Go interfaces. This is vaguely similar to how Rust does it, and quite different from the C++ approach.<p><i>"This design does not support template metaprogramming or any other form of compile time programming."</i><p>[1] <a href="https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md" rel="nofollow">https://go.googlesource.com/proposal/+/refs/heads/master/des...</a>
I rarely find myself frustrated with the lack of generics in Go and am so glad to never deal with the kind of over-engineered generic madness that is so common in Java, except...<p>When dealing with collections. It's maddening to have to keep duplicating basic functions like getting the keys from a map, or checking if a slice contains a given item.
I've been heavy into Go the past year. I love the simple interfaces they've built over some rather complicated things (concurrency, cross-compilation, networking, etc), which really do tend to just work.<p>I fear that Go will eventually turn into something where we look back and realize we've lost something important by gaining a lot of less importants. The impulse to <i>change things</i> is just too strong these days. C89 has done just fine unchanged for 30 years.<p>All I want is a C+=1 I can rely on for the next 30 years.
Here's the actual proposal:<p><a href="https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md" rel="nofollow">https://go.googlesource.com/proposal/+/refs/heads/master/des...</a>
I hope at some point they manage to add it.<p>I, however, discovered Rust in the meanwhile. It has generics.
And it is not too complex either and has quite a few other bonuses.
I look forward to generics in Go. Yes, it's possible to do it with reflection, interfaces and interface{}, but it's not typesafe, it's not fast, and it's prone to code bloat.<p>I'm a fairly late-comer to generics, I never programmed seriously in C++, I avoided generics in Java initially, and I wrote a lot of code in less statically-typed languages. Ever since the first serious talk of generics in Go 2.0 I've endeavored to educate myself and I now am very strongly in favor of them.
I'm really mixed about this. As a developer I would <i>love</i> having generics in Go. I can think of a few places in my code I can greatly simplify if they were implemented now.<p>However, as someone who reads <i>other people's</i> Go code, I'm not a huge fan. One of the greatest things about Go is that a developer can usually one-shot read and understand almost anybody's code because there's a simplicity "forcing-function" applied to everything. To lose that would be a shame.
It's too bad this is targeting end of year, I have so many applications for this--test assertions, http controllers, SQL--this will remove a lot of duplicate code. I also think it will expand use cases for Go, especially in the UX area where you have to implement duplicative getters and setters.
Another comment mentions this is the third (serious) attempt at adding generics to Go.<p>Is there any concise history of these attempts (including this one)? I'd like to understand the gist of these proposals and what ultimately derailed them.<p>By themselves these proposals are pretty inscurtable.
I find the proposal interesting. Type constraints might help to reason about a given abstraction. If I understand correctly they behave quasi like sum types over interfaces.<p>From skimming here: <a href="https://go.googlesource.com/proposal/+/master/design/go2draft-type-parameters.md" rel="nofollow">https://go.googlesource.com/proposal/+/master/design/go2draf...</a><p>They don't feel like generics in for example Java (my Java is rudimentary), but rather like an abstraction over interfaces.<p>Can anyone elaborate on this?
As much as I've cursed the lack of generics and the limited expressiveness of Go's type system, it's hard for me to reconcile these proposals with what I know of Go. Go was conceived as a small language, a successor to C, and purposely eschewed "new-fangled" features of modern languages. Whether the result is good is a matter of taste, but I feel that retroactively bolting on a modern type system will simultaneously (a) undercut the simplicity of the core language and (b) produce a language that is not as clean as those conceived with generics from the beginning.
"If the proposal is accepted, our goal will be to have a complete, though perhaps not fully optimized, implementation for people to try by the end of the year, perhaps as part of the Go 1.18 betas."
Side tracking a bit: I wish there was a popular programming language like Go with rust-like package manager, Python style syntax and ability to hack, compilable, classic (classes, methods), and fast. Or I wish Go had classic OOP and raise Exception methods.<p>Basically, I want fast statically typed python with better package management. Or other way to put it, I want Go with classic OOP and Exceptions.
The carefulness of the Go team when introducing new features is remarkable.<p>After many years chasing the newest, shiniest and best tools I can't appreciate stability and a large and useful standard lib enough. I finally understood the importance of the boring stack.<p>I don't need generics in Go, but I'm happy they are coming. Especially for collection methods.
Finally. Hope it gets approved.<p>It's strange that they don't consider Print[T](x T) instead of Print[T any](t T). The "any" could just be omitted without loss of anything. Especially since repeated types with the same constraints indeed DO omit it! Print2[T1, T2 any]
> Interface types used as type constraints can have a list of predeclared types; only type arguments that match one of those types satisfy the constraint.<p>Wait... But why?gif
every language designer who does not understand c++ is doomed to reinvent it<p>I mean, seriously,<p><pre><code> func F[T any](p T) { ... }</code></pre>
Generics are awful. They solve no problem in the domain space, only the developer space.<p>Which then creates the problem of developers who insist on writing infinitely extensible generics with indecipherable bounds.<p>Just repeat code. You'll be fine.<p>If you find yourself repeating a LOT of code because Go does not support generics, maybe stop and think about your design. Putting generics in as an escape hatch will do you more than good, guaranteed