[egonelbre]

Thanks, didn't intend for it to end up on HackerNews - at least not yet. It's still the first draft, most of it I wrote up in ~2hours. I mentioned on the forum that this document (currently) is highly biased towards my views, this is unfortunate, but this can only be fixed after numerous reviews.

Thanks for pointing out the problems with wording. I'm slowly fixing those. I've changed that "best" to "As with any feature it should solve a set of problems, if there are better ways of solving the problems, those should be used instead."... it's better but not perfect.

"in other cases the hit from interface{}" - added that addition to the alternatives section.

Generics don't have to be perfect, but it must be actually useful and it mustn't compromise simplicity of Go.

[coldtea]

>* Thanks, didn't intend for it to end up on HackerNews - at least not yet. It's still the first draft, most of it I wrote up in ~2hours. I mentioned on the forum that this document (currently) is highly biased towards my views, this is unfortunate, but this can only be fixed after numerous reviews. Thanks for pointing out the problems with wording.*

Thanks for not being defensive and taking my rather harsh critique lightly!

I wasn't trying to attack your specific document either, it's just that those things have often been repeated (often verbatim) by the Go-dev camp.

[egonelbre]

Basically, I have nothing to be defensive about - it's a summary of discussions, which means that any properly stated argument should be incorporated to the document, no matter what I personally feel about that argument. Although, the content has to be moderated somehow, I dislike deciding what is "properly stated" argument, but I don't really have a better idea how to do it either, at least not yet.

Personally, I stand in the middle of the generics discussion so I pretty much can see both sides as a valid approach. And it's a WIP and I know if one person writes it, it will be biased no matter how hard you try.

PS: I find the "straight to the point" comments much more useful - they are much easier to understand. So don't worry about it :)

[NateDad]

Put a big comment on the top DRAFT!! STILL IN PROCESS!! or something.

[waps]

It doesn't mention the major inconsistencies in golang at all.

Go has generics. For arrays, slices, channels, maps, and some "standard" library functions. Go has generic functions. "append" being the obvious example. Go has polymorphic functions : append, make, ... If you look at the compiler source, the type system has generics, to a large extent. It's simply not accessible to normal programmers, instead only allowed for golang's authors.

As if this is not bad enough. Go cheats the type system in thoroughly non-obvious ways to get more C-like behaviours that obviously do not improve safety or programmer productivity.

Go has shudder return value polymorphic functions. Range being the obvious, but not only example (range changes in meaning depending on it's parameters AND on what you assign the result to).

As for your boxing argument. As soon as you use reflect, you're boxing everything. Oh wait, if you use a package that uses reflect, of course you're also boxing everything. Surely that can't be much ... hmmm half the standard library uses reflect. Fmt, everything in encoding, text or html templates, rpc, jsonrpc ... No need for boxing, or compile-time function evaluation or generics (all present better solutions to this, for the CTFE solution see D-lang).

Golang even has functions with type parameters. Make and new being the obvious examples. Again, this is present in the type system (not just there, also in reflect, things like printf, ...). It's simply not made accessible to us lowly go programmers.

So can we please stop with the crap that generics aren't necessary ? That nobody uses advanced type system features ? Or that polymorphism isn't necessary ? It's crap, and obviously the golang authors don't actually believe that. They just think that only they can be trusted to write such functions and that their datastructures are all anyone ever needs. If you disagree with that assessment (and everybody will, soon) Go is not for you.

So Go is simply a throwback to pre-80s programming languages, and a perfect illustration of the frustrations that led to the development and extension of the C++/Java/C# programming languages. If you give people the minimal implementation of sorting an array of structs, it becomes blatantly obvious why other languages are necessary.

The more I write Go, the more I yearn for C++. There is nothing in the C++ language that I can't do for my own datastructures/functions/... That is a huge feature, and may I just say :

From my cold, dead hands !

Btw : there is a better solution to generics as well at compiler-level, that is used in things like the CLR. First, generate unboxed versions of functions where that makes sense. If specializations are possible for 1-bit, 1-byte, 2-byte, 4-byte and 8-byte primitive data types, expand those. Then for anything bigger, like structs, create a boxed implementation, because for structs there is no longer any advantage to working unboxed. Then make it possible to pass in the version to be used in a parameter, so you don't have a combinatorial explosion when many type parameters are given.

e.g. http://research.microsoft.com/pubs/64031/designandimplementa...

[ansible]

Btw : there is a better solution to generics as well at compiler-level, that is used in things like the CLR. First, generate unboxed versions of functions where that makes sense. If specializations are possible for 1-bit, 1-byte, 2-byte, 4-byte and 8-byte primitive data types, expand those. Then for anything bigger, like structs, create a boxed implementation, because for structs there is no longer any advantage to working unboxed. Then make it possible to pass in the version to be used in a parameter, so you don't have a combinatorial explosion when many type parameters are given.

That sounds sensible.

I'd like to figure out a way to extend the concept of interfaces to cover use cases like generic containers, but I'm not quite sure how that would work.

[michielvoo]

Regarding the CLR, the document links to MSDN [1] where it says that "the runtime generates a specialized version".

[1] http://msdn.microsoft.com/en-us/library/f4a6ta2h.aspx

[egonelbre]

> It doesn't mention the major inconsistencies in golang at all.

It has little relevance to "Generics". They are simply how Go is implemented, the question is whether "Generics" as a user implementable thing should be added.

> CLR

From my quick reasearch, it uses runtime code generation and Go must run in environments where that is disallowed.

[pjmlp]

Regarding the CLR you have ahead of time compilers in the form of Mono for iOS, Windows Phone, Bartok, ngen and now .NET Native.

How the generic code generation differs from the JIT approach I don't know.

[waps]

It has relevance to generics. Right now the question implies Go does not have generics, which is not true at all. The question should be reworded :

Go has generic types and generic/polymorphic functions. Therefore all the focus on that such functions are not necessary/useful seems entirely beside the point, the result of misunderstanding. Can normal Go programmers please be allowed to make use of that feature ?