Learning Go

Chapter 15. Welcome to the Future: Generics in Go

Despite the lower priority placed on features, Go isn’t a static, unchanging language. New features are adopted slowly, after much discussion and experimentation. Since the initial release of Go 1.0, there have been significant changes to the patterns that define idiomatic Go. The first was the adoption of the context in Go 1.7. This was followed by the adoption of modules in Go 1.11 and error wrapping in Go 1.13.

The next big change has arrived. Version 1.18 of Go includes an implementation of type parameters, which are colloquially referred to as generics. In this chapter we’ll explore why people want generics, what Go’s implementation of generics can do, what generics can’t do, and how they might change idiomatic patterns.

Generics Reduce Repetitive Code and Increase Type Safety

Go is a statically typed language, which means that the types of variables and parameters are checked when the code is compiled. Built-in types (maps, slices, channels) and functions (such as len, cap, or make) are able to accept and return values of different concrete types, but until Go 1.18, user-defined Go types and functions could not.

If you are familiar with dynamically typed languages, where types are not evaluated until the code runs, you might not understand what the fuss is about generics, and you might be a bit unclear on what they are. It helps if you think of them as “type parameters.” We are used to writing functions that take in parameters ...