My personal hypothesis is that many libraries follow the official Go release policy[1]. Due to the fact that generics were introduced with v1.18 and we now have v1.19, libraries would be bound to the features that were available with v1.17, unless they spend effort on working around this by implementing the respective build flags that make generics available exclusively for >=v1.18. However this is just an assumption.
According to the Go Developer Survey 2022 Q2[2], 1 in 4 respondents said they've already started using generics in their Go code and 14% have started using generics in production code.
[1] https://go.dev/doc/devel/release [2] https://go.dev/blog/survey2022-q2-results
So until the learning material catches up and until new libraries are written, or old ones have a reason to be updated, you won't see generics widely used.
For instance, we have an internal library that helps us create and perform common operations on concurrency-safe maps. Being able to pass and return arbitrary structs to/from those functions has made our codebase much cleaner and easier to work with.
Please take my response with a grain of salt, as we have not benchmarked or otherwise compared (via escape analysis, etc.) those generic functions against any non-generic equivalents.
It's a very frameworky piece of code, which is exactly the kind of thing that can benefit from generics.
https://www.scylladb.com/2022/04/27/shaving-40-off-googles-b...
The only time I have used them in the last year was building a generic LRU memory cache and it worked wonderfully.
Generics are typically very useful in a few very specific contexts but in most applications you can get by fine without them.
Library authors want to support old go versions, and the library usage of Generics might not work on that older version.
I just started using generics because I wanted a couple release cycles for issues to be shaken out. I would suggest to most library authors to wait until 1.20 is released before using generics, and if you are doing anything slightly sophisticated to make sure you have a CI that builds with older versions of Go.
If you are writing application code, then go ahead and use generics, but generics are usually most useful for libraries.
I was recently able to fork a library for better error handling in Go and make a version similar to the try proposal. This library wouldn't have been possible without generics: https://github.com/gregwebs/try
There are many experienced developers who (through long experience fighting C++) have come to understand that using a simple language (like Go or C) allows you focus on the algorithms and complexity of the problem you're trying to solve. This is part of the Go culture.
A junior developer might not understand this yet. He's still having fun finding obscure and convoluted contortions of the language that allow him to save little or no effort... not yet realizing that nobody gives a shit and he's wasting his time and the time of his coworkers.
I still haven't learned generics.
In particular I looked at places where we use code generation and places where we use reflection - both good candidates for generics.
Alas I found generics just weren't powerful enough to replace these uses, it would need a more powerful macro system.
I think go generics are great for container libraries. I've written and debugged enough of those to be very happy using a library.
I doubt Go will ever get macros though.
I really like Zig's comptime mechanism - that seems like the right amount of power and it's all just zig code!
Mostly though, most of the stuff people were complaining about regarding Go's lack of generics were really minor things, like map/filter versus for loops. There are some things you really couldn't do easily in Go without generics, but for the most part Go's critics were just obstinate about not wanting to learn a new style of programming (so much so that many are willing to forsake all of Go's considerable advantages with respect to tooling, deployment model, build times, package management, ecosystem, etc). Moreover, Go's critics were (and still are) unwilling to admit there are benefits to avoiding generics--the code becomes less abstract and more standard as there are fewer ways to express a given solution.
If you really want to dunk on Go, the more valid criticism is that it lacks sum types, and unlike converting a map/filter chain to a for loop, there is no good way to emulate sum types in Go (there are some tricks to get close, but they involve far more boilerplate and they don't give exhaustiveness checks (and the performance tradeoffs suck).
Go is the cloud native language, there is no need to change your production code only just to add the latest shiny feature, that goes against the philosophy of Go
people will adopt the new features slowly but surely as they get battle tested
have a function take in an array of T
T is generic with type constraint call Constraint
problem is calling that function wont work because it has to instantiated with one of the types found in the Constraint which beats the whole purpose. I need this to pass in structs that belong to Constraint.
I tried a multitude of different things and nothing seemed to work.
I ended up reading the Go library for how it handles SPrintF args and did something similar with a type switch and reflection wizardry.
Im still a junior programmer so it could be that I just didnt know how or I underestimate the solution for this.
But I figured once we have a type Constraint defined with a function, it should be relatively simple to not have to instantiate it with ONE concrete type and allow the Constraint types as args.
if anyone knows a better way to do this please let me know
So was not having generics a deal-breaker? No! Are they useful? Yes!