I really like the syntax used to declare generic type parameters to functions in ML-type languages like F#.<p>Writing the below in other languages (pseudocode) feels repetitive in the same way that `Thing thing = new Thing()` did back before `var` or `auto` types became popular:<p><pre><code> list<Y> Map<X, Y>(list<X> inputs, X->Y mapping)
</code></pre>
Why do I need to put <X, Y> in brackets after Map? To tell the compiler that these are generics, not attempts to reference actual specific types that just happen to have crappy, nondescript names like X and Y.<p>In F# and friends, there is no need to put a bracketed block declaring which types are generic parameters. I would simply write:<p><pre><code> let map (inputs: list<'x>) (mapping: 'x -> 'y) : list<'y> = ...
</code></pre>
The little apostrophe or tick mark before the type name tells the compiler it's a generic type parameter. It's not legal to name a concrete type with a leading tick mark, so there can be no mix-up. At first it looks ugly, but once you are used to it, it is natural and less cluttered than having to have these separate bracketed declarations for "uh-oh, here comes a generic".<p>But I suspect Go will always want more explicit syntax for generics. In part out of backwards compatibility, but largely because Go's designers see generics as an advanced, occasionally useful feature. Correspondingly they'll want the presence of a generic function to have ugly syntactical warning signs: here be dragons.<p>Functional languages usually take the opposite approach and see a fully generic function as <i>less</i> complex than one for a specific type, because just by looking at its signature, you know it doesn't require anything special about the input objects it's going to work on. It is not going to be calling methods on them or messing with their guts. It's just treating them as black-box, could-be-anything cards to be shuffled around from point A to point B.