[camus2]

> hell no, if generics get into go I'll have to find another favorite language.

Well, I hope go get generics fast then. Seriously, what is this community that rejects any possible enhancement to a language? Even C gets new features albeit slowly. A language that doesn't evolve is a dead one.

There is nothing complicated with generics, they are just incomplete types, that's all. Generics =/= C++ templates.

Ada has a great implementation of generic programming which forces the developer to complete generic types before using them. In fact Ada got a lot of things that go got wrong despite being way older, especially when it comes to concurrency and types.

Package based generics make them completely compile time and runtime safe, no type erasure. The'd be the equivalent of reflect.MakeFunc or reflect.MakeStruct at compile time, so without any performance penality or ugly reflection, which go has right now.

[geodel]

I feel what is with this demand that Go has to have generics when there are some excellent languages with Generics available.

[axaxs]

I'm on the fence about generics...but to answer your question generally...it's not all 'enhancements', it's making a language less readable. Sure, I can choose never to use it. But now I have (more) trouble reading others code. Go's strength, to me, is readability.

[nevercomments]

People programming in Go today already have workarounds to provide the functionality of generics, but at the cost of type safety and speed.

It is very common (especially in libraries) to pass `interface{}` around and use reflection to do manual type checking and type casting.

With generics the code that uses `interface{}` today would actually be much more readable, because the intention of the author would be clear.