Toward Go 2
<p><pre><code>    &gt; I can&#x27;t answer a design question like whether to support 
    &gt; generic methods, which is to say methods that are
    &gt; parameterized separately from the receiver.
</code></pre>
I work on the Dart language. Dart was initially designed with generic classes but not generic methods. Even at the time, some people on the team felt Dart should have had both.<p>We proceeded that way for several years. It was annoying, but tolerable because of Dart&#x27;s optional type system -- you can sneak around the type checker really easily anyway, so in most cases you can just use &quot;dynamic&quot; instead of a generic method and get your code to run. Of course, it won&#x27;t be type safe, but it will at least mostly do what you want.<p>When we later moved to a sound static type system, generic methods were a key part of that. Even though end users don&#x27;t define their own generic methods very often, they use them <i>all</i> the time. Critical common core library methods like Iterable.map() are generic methods and need to be in order to be safely, precisely typed.<p>This is partially because functional-styled code is fairly idiomatic on Dart. You see lots of higher-order methods for things like manipulating sequences. Go has lambdas, but stylistically tends to be more imperative, so I&#x27;m not sure if they&#x27;ll feel the same pressure.<p>I do think if you add generic types without generic methods, you will run into their lack. Methods are how you abstract over and reuse behavior. If you have generic methods without generic classes, you lose the ability to abstract over operations that happen to use generic classes.<p>A simple example is a constructor function. If you define a generic class that needs some kind of initialization (discouraged in Go, but it still happens), you really need that constructor to be generic too.