The <a href="https://victoriametrics.com/blog/go-1-27/index.html" author="Jesús Espino" source="Victoria Metrics">Go 1.27 interactive tour</a> describes an improvement in the language that allows methods to declare type parameters. <bq>This is the headline of the release. A method declaration may now declare its own type parameters, independent of the receiver’s. Before Go 1.27, only top-level functions could be generic, so a generic operation on a type had to live as a package-level function instead of a method.</bq> The following example shows a <c>findIndex</c> implementation that expects only that the type of the array's elements be <c>Equatable</c>. <img src="{att_link}go_findindex_generic_implementation.webp" href="{att_link}go_findindex_generic_implementation.webp" align="none" caption="Go findIndex generic implementation" scale="80%"> None of this is surprising in any way. This is a very common pattern known in many, many other languages. When Go first came out without generics, I didn't even consider it as a viable programming language---it's a low-level system language---because I knew that I would be copy/pasting a lot of code or doing handstands to try to figure out how to avoid doing so. A few releases back, Go finally got generics---which probably caused all sorts of upgrade headaches---and now it's getting generic method parameters. Cool. I think it's great for them but it's fascinating to watch the inevitable march toward reinventing all of the things that we already we knew we needed thirty years ago in order to create properly statically typed code while keeping repetition low. I guess you could say that Go bravely tried to prove that generics weren't necessary but it's hard not think about all of the boilerplate people were forced to write for years and then the upgrade headaches and rewrites they were forced to endure when the feature was introduced later.