Hacker News Reader

Comment by hota_mazi | Hacker News Reader

> Because we will not know what the best practices are for using generics,

Well, you could... take a look at languages created these past twenty years that support generics, learn lessons from that, and see how these lessons could apply to Go.

But well, the Go team is not exactly known for paying much attention to the state of programming language theory, so I guess that's out.

View on HN

Given that every language is different, this is basically reasoning by analogy. Sometimes analogies are useful for explaining things, but they're not a reliable way of determining what will definitely work.

Reasoning by analogy in a sneering way doesn't make it work better.

Programming languages differ, yes, but not so much that they face completely different design decisions. Also, it's not "reasoning by analogy", it's learning from others.

In fact, why stop at generics? Why not go back and question structured programming? Or strong typing? Because structured programming and strong typing has proven to be extremely useful. Same as generics in statically typed languages.

Maybe reasoning by analogy and learning from others are about the same thing?

How much you should rely on others' experience, and when you should consider it a positive example versus something to learn from by avoiding, is going to be a judgement call.

Trivia: parametric polymorphism (aka generics) was first done in ML, 46 years ago. WP cites this reference:

Milner, R., Morris, L., Newey, M. "A Logic for Computable Functions with reflexive and polymorphic types", Proc. Conference on Proving and Improving Programs, Arc-et-Senans (1975)

(And of coures we've been able to write generic code in dynamic languages for a long time as this is a static typing concept)

I think Go is all the better for not rashly copying every idea from every programming language. The delay on generics is a small price to pay (if indeed a “price” at all) to have such a simple, ruggedly utilitarian language which also happens to be an absolute joy to use.

You can do that, but that's still not as good as direct experience with Go generics in Go code. Those wouldn't be best practices, they would be guidelines.

It does seem strange. This is a problem that has been long solved elsewhere. I don't get the fuss over it.

Go is Special and not comparable to these lesser languages.

Reply on news.ycombinator.com