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