Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Adding generics to Java and C after several years, shows how successfully the "wait and see" actually works, versus languages that have supported them from the get go.

CLU was designed in 1975 and ML in 1973, several languages with support for some kind of generics have been born and died since then.

So in 42 years, there wasn't a single generic implementation that could fit Go's design goals, other than not having generics at all?!



But Go has not existed for 42 years. Fitting any of those models on Go is exactly what should be avoided unless one of those models magically was a perfect fit for Go which came out just a few years ago.


That is just hand waving, it is more than clear that //go:generate, 90's style is the the only way accepted by Go design team.

There is nothing special in Go's type system that hasn't been tried out in 42 years of generics CS research.


Magically? It would take magic for one of these models to NOT be a perfect fit for Go.

The fact that Go "has not existed for 42 years" is irrelevant -- almost all of its characteristics have been present for 3 to 5 decades, even altogether in the same language(s).

E.g. http://cowlark.com/2009-11-15-go/


Seems author has added an update after 6 years:

"..Updated 2015-09-25: So, about six years later, people are still reading this. I'm not sure how to feel about this; Looking at it now, it's incoherent, badly argued, and a lot of the details are simply wrong. But 1000 hits a month indicate that people still get value out of it."

But this article link is still quite handy for random proof of Go badness.


Whatever the author added, the original points still stand.

He might have changed his mind, but the facts are more stubborn.


Especially since he adds "Don't get me wrong; I still think that Go is a terrible language. I now work for a company that does a lot of it, and every time I touch it it depresses me a little more".


The "wait and see" approach as you call it, means that "Generics" (a.k.a. parametric polymorphism) have had to be retro-fitted to languages like Java. This means they are more complex than they need to be and have some ugly edge cases.


This. We still can't overload foo(List<Integer> x) and foo(List<String> x) because vintage 2004 JVMs wouldn't be able to distinguish them. Type erasure was a horrible compromise from which Java will probably never completely recover.


In C11 they are even uglier with the _Generic selector, which understandably was made to work together with how generics were done via pre-processor macros.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: