Hacker News Reader

Comment by Strom | Hacker News Reader

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 Go specific things like how to deal with legacy std library parts that are made obsolete by generics.

View on HN

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.

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.

So you will drop any existing dep your project has that adopts generics ?

Fortunately, they fixed dependency management first, so you can simply stop updating any dependency that adopts generics!

Cool and what happens with security updates?

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?

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.

Exactly, they make users of Go copy-paste their own code instead.

Reply on news.ycombinator.com