5 ms·

Go is not in the business of copy-pasting other language designs. That much should be obvious by now. The questions aren't around the algorithms. They're about

• qaq 5y ago
  Yes NIH at Google is on the level of it's own. Look at any ecosystem that used this logic to push something off and you will see a badly fractured community that never fully reconsolidates. I'd rather depend on std lib with warts than have my deps depend on 3 incompatible versions of generic map from 3 dif. libs.
  • marcus_holmes 5y ago
    Simple solution: don't use a dep that uses generics until the fracturing is gone. Take the same approach as the Go team and let the use of generics mature and a consensus build on where/how they should be used. There's no need for generics in the short term. We've survived for 11 years without them, we can manage another couple while we work out how to best use them.
    • qaq 5y ago
      So you will drop any existing dep your project has that adopts generics ?
      • yalue 5y ago
        Fortunately, they fixed dependency management first, so you can simply stop updating any dependency that adopts generics!
        • qaq 5y ago
          Cool and what happens with security updates?
          • sangnoir 5y ago
            Libraries that don't do point-release security updates for major versions should not be trusted, or used in production. Libraries that do release security updates, but introduce new language features like generics in those point-releases also shouldn't be trusted, and have no place in production. Why should I upgrade my language version to get a security fix?
      • marcus_holmes 5y ago
        Yes. Because if the code works now then it doesn't need generics, so the only reason for adding generics immediately is because the author wants to play with the new toy. And I don't need that kind of attitude in code I rely on.
• pjmlp 5y ago
  Exactly, they make users of Go copy-paste their own code instead.