[marcus_holmes]

Seconded. Unlike Node/Ruby/most other modern languages, Go devs actively avoid including dependencies if at all possible.

And contrary to rumour, this is not because Go's dependency management sucks. It's more about the pursuit of simplicity, and avoidance of magic.

You can write pretty much anything using just the standard library (and some of the official packages, like the crypto ones). As the parent said, it's good practice to go as far as possible with just the stdlib.

[oceanswave]

So go is about recreating the wheel, over and over again

[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.