probably this: http://research.swtch.com/generic ? go had 3 options for implementing generics:

1. leave generics out : the c way (slows programmer)

2. do it at compile time: c++ way (slows compilation)

3. box/unbox everything implicitly: java way (poor perf)

Also look at a list of proposed ways to add generics (and why they didn't make it): https://github.com/remyoudompheng/go-misc/blob/master/generi...

Hm. Which of these does C# use? Which does Haskell use?

Regarding C# it depends on which compiler you talk about.

Microsoft's current JIT/NGEN, generate a single version for reference types and a separate version for each value type. So a mix of Java/C++ approaches.

Not sure what the new JIT/NGEN compilers, RyuJIT will use.

I also don't know what approaches are taken by Mono, Bartok and IL2CPU, but they might be similar.

Yep, now I can see why this is trilema is "incomplete at best" - c# and other use what can be described as a mixture of these three approaches.

I was going to say that the c# compiler is fast enough despite this, but then I remembered that one of go's selling points is that the go compiler is blindingly fast compared to languages such as c#. Perhaps maintaining that performance with generics is a real issue.

Although any language with modules is fast enough, compared with C and C++.

Many old timers like myself can remember the blazing fast compile times of Modula-2 and Turbo Pascal compilers in MS-DOS systems.

Go compilers also lack a strong optimizer, which is tends to slow down compilation.

I believe C# does it at runtime for reference types, and compile time for value types, so that you don't eat the cost of boxing at runtime. It doesn't make sense to make separate compile time generic types for reference types in C# since the type is basically constrained to using system.object members anyway (unless you add type constraints to the generic type class definition).

Haskell: A mix of 2 and 3.

It's ironic considering that the Go developers want the best for the programmer (That's why they work so hard on the Go tool for example).

Well, the default case (leave them out, make do for the time being) allows the option of adding generics later on (in a hypothetical Go 2.0 or later).

Using a half-baked model and implementation now boxes the language in later on.