Go released version 1.18 in March 2022. Generic programming lets you write functions that can accept and return more flexible types.

The Go programming language has evolved a lot since it was first published in 2009. Go 1.18 was a highly-anticipated release due to its support for generics and many other important updates. Go released version 1.18 in March 2022. Generic programming lets you write functions that can accept and return more flexible types. Before support for generics, you needed to explicitly state parameter types and return types. The simplest form of generics allows you to specify untyped parameters:

Func PrintAnything[T any](thing T) {

Fmt.Println(thing)

}

But generics offer much more power than just this. You can declare almost any combination and granularity of type for parameters. For example, you can use the constraints package to write a function that operates on any value that you can order. This includes int, floats, and strings.

In the current implementation of Generics in 1.18, every runtime invocation of a generic function will transparently receive as its first argument a static dictionary with metadata about the arguments being passed to the function. The dictionary will be placed in register AX for AMD64, and in the stack in platforms where the Go compiler doesn't support register-based calling conventions yet. The full implementation details for these dictionaries are explained in depth in the aforementioned design document, but as a summary, they include all the required type metadata to pass the arguments to further generic functions, to convert them from/to interfaces, and most relevantly to us, to call methods on them. That's right, after the monomorphization step, the generated function shape needs to take as a runtime input the virtual method tables for all its generic arguments. Intuitively, we can venture that while this greatly reduces that amount of unique code being generated, this kind of broad monomorphization does not lend itself to de-virtualization, to inlining, or really to any kind of performance optimization.

In fact, it might seem that for the vast majority of Go code, making it generic will imply making it slower. But before we start sinking into a deep pit of despair, let us run some benchmarks, look at some assembly and verify some behaviors.