3 ms·

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

• sethammons 8y ago
  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 8y ago
    What is the Go alternative to generics?
    • marcus_holmes 8y ago
      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.