[sethammons]

Not really. Generally, the wheel you need and the wheel I need are a bit different. Instead of using some bloated "all-wheel," developers choose their custom wheel.

Simple example, SyncMap. This is a general purpose all-wheel, and as such, due to Go's type system, you have to use runtime type assertions against it. If I need a lockable map, I just make one and it is of the type I need, say map[string]*Foo. I just wrap it in a struct with a lock and I'm done.

For more complicated things, most everyone will pull in a package. I'm not going to waste some time making a Redis or Kafka package. For a web server, I may pull in a different muxer, but only if needed.

[matte_black]

What is the Go alternative to generics?

[marcus_holmes]

specifics?

Joking aside, that's pretty much it. The usual method for go devs is to solve the specific problem in front of you (and accepting a certain amount of duplication) rather than creating generic solutions that have a wider scope than they need. Once it's all working, refactoring can often remove the duplication and provide a better solution than the generic one would have provided (because by then you know the problem domain better).

I've been coding in Go for a few years, and only a couple of times run into the "shit, I need generics here" problem.

And yes, I get that this means that the Go answer to generics is "you don't need generics" ;) Which sounds like such bullshit of course.