Hacker News new | comments | ask | show | jobs | submit login

Generics as a language retrofit tend to be ugly. See C++.

I was at one time plugging for parameterized types. Go already has parameterized types; "map" and "chan" are parameterized types. You write "make(chan int)" and "make(map[string] int)". You just can't define new parameterized types; "map" and "chan" are all you get. With parameterized types, you could create more generic data structures; if you needed a generic b-tree or a quadtree library, you could have one. Maps in Go are more special than they should be.

Parameterized types are less powerful than generics, but not too far from what Go now has. The goals in the document mentioned here require generics with all the bells and whistles. Remember, Go still has reflection; if you don't need high performance, you can simulate generics at runtime.




Reflection comes without the compile time guarantees (parametric polymorphism offers), and that is a far greater loss than the missed performance opportunities.


But it is useful, and offer you compile time checking.

The current interface{} workaround doesn't quite solve the same problem, rather it is like a bad excuse.


C# generics work beautifully and they were retrofitted. Later language additions like LINQ and extensions take advantage of generics as well.


Depends on the implementation. See Java.




Applications are open for YC Summer 2019

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

Search: