Compile-time Feedback to Generics in Go 2 Draft Designs
Golang compiles fast, and this is an important feature when it is compared to other languages. The draft design makes a small reference to compile time performance implementation and efficiency but I believe this has to be clarified further.
Let me address the quote "In other words, this design permits people to stop choosing slow programmers, and permits the implementation to decide between slow compilers (compile each set of type arguments separately) or slow execution times (use method calls for each operation on a value of a type argument)". "Slow programmers" is the current 'do it your own way approach', which is largely agreed is not good enough. But "slow execution times", also referred to as "compiled using an interface-based approach" (for generic functions at least) is, if I understand it correctly, a thin layer on top of an interface based implementation. This is hardly an improvement over what we have now and generally not what most of us are looking for, especially given a big use for generics would be algos and performance is likely relevant.
The implementation I believe the community is looking for is the "compile each set of type arguments separately" one, but that may come at some significant compile-time cost. What does the proposal suggest to minimize this? Also worth highlighting is that, once in the language, there is no stopping users from abusing generics much like it has been done in other languages, likely degrading the compile time for code relying excessively on generics (directly or through libraries).
As a form of a solution (or at least food for thought), some of what generics offers can be achieved currently through code generation, if in a more inconvenient way.
I use genny to generate functions like Max([]T) T, Min …, Reverse …, Filter …, Equal …, etc. for many built in types.
In fact I believe all of the examples in the proposal would be fairly easy to implement in this way.
This has the advantage that the generated code is installed in GOPATH/pkg as package objects (like any other go code), meaning compile time does not degrade.
Can an implementation of generics explore using GOPATH/pkg to install package objects for instances of generics?
Also an interesting article from @davecheney on the how the runtime imlpements maps efficiently which highlights some of these compile time concerns. It also mentions binary size - another issue the generics proposal should probably comment on further.