Chapter 4 The Type System on Go: Under the Hood

4.1 The Runtime Type System

Mon, 01 Jan 0001 00:00:00 +0000

4.1 The Runtime Type System

Go is a statically typed language, and type checking happens at compile time. Yet Go still keeps a substantial amount of runtime type information (RTTI), and it is precisely this that supports interfaces (4.2), type assertions, type switches, reflection, and the garbage collector’s precise identification of pointers. This section answers a seemingly simple question: of the type machinery that exists at compile time, what survives into the runtime, in what form is it kept, and what capabilities does it underpin. Once you understand the small structure called the type descriptor in this section, the interface (4.2), reflection, and precise GC (13) all gain a common footing.

4.2 Interfaces

Mon, 01 Jan 0001 00:00:00 +0000

4.2 Interfaces

Interfaces are the soul of Go’s type system. They decouple behavior from implementation, and they do it in an unusual way: structural, implicit satisfaction, unlike most mainstream languages. This section looks at how interfaces are represented at runtime, how methods are dispatched dynamically, how type assertions are realized, and where this design sits within the broader lineage of polymorphism. Following the approach of the previous sections, the structs given below are trimmed-down sketches: they keep only the fields relevant to the design, with comments explaining why each one exists. For the full definitions, compare against runtime/runtime2.go, internal/abi/iface.go, and runtime/iface.go.

4.3 Type Aliases

Mon, 01 Jan 0001 00:00:00 +0000

4.3 Type Aliases

type A = B (a type alias) and type A B (defining a new type) differ by a single equals sign, yet the semantics are fundamentally different. The former merely gives a new name to an existing type; the latter creates a brand-new type with its own independent identity. The distinction looks minor, but it pulls on the whole set of rules governing type equality, method sets, and assignability (4.1), and it also pulls on a question Go has always cared about: when a body of code is no longer maintained by its original author yet still has to evolve without breaking compatibility, how should a type migrate from one package to another. This section first makes the semantics of aliases and defined types clear, then explains why aliases were introduced in Go 1.9, and finally looks at the generic capability they gained in Go 1.24.