The Go Pipeline

Go's pipeline has fewer distinct representations than any other statically typed language in this module, and that is the point rather than an omission. Parse, type-check, build SSA, optimize modestly, emit machine code, link. There is no separate high-level IR to desugar into, no trait resolution to run to a fixed point, no monomorphization pass multiplying the work, and no LLVM.

The unit is the package. All the files in a package are parsed together, so order does not matter and nothing needs declaring before use, and the compiler emits one object file plus the export summary. Dependents read the summary — a few kilobytes describing exported types, function signatures, constants and the bodies of inlinable functions — instead of reparsing anything.

Compare that with [[cpp-pipeline]], where a two-line file that includes one standard header becomes a thirty-eight-thousand-line translation unit, and every other file that includes the same header produces its own copy. Go pays that cost once per package, ever, rather than once per including file. The saving is not a clever implementation; it is a different model, and the language was shaped around it.

The compiler is fast because it was never asked to do the expensive things. There is no preprocessor, so nothing is re-expanded per file. There are no headers, so a dependent reads a summary instead of source. Import cycles are an error, so the build is a topological sort over a directed acyclic graph of packages, and each is compiled exactly once from summaries that are already finished. The type system has no inference beyond the local := form, no implicit numeric conversions and no user-defined operator overloading, so type checking is close to a single pass.

And the feature set is small on purpose. There is no metaprogramming facility that runs code at compile time, no template language, no macro system, and until 1.18 no generics at all. Every one of those is a thing the compiler does not have to do, and the absence of each is also a real expressive loss that Go accepts explicitly.

The counterpart is code generation. Because the language cannot express certain abstractions, the ecosystem generates source instead — go generate, stringer, mocking tools, protobuf compilers. That work still happens, but it happens in a separate, cacheable step that produces ordinary Go the compiler checks normally, with ordinary error messages. It is a deliberate relocation of metaprogramming out of the compiler and into the build.

The gc toolchain does not use LLVM. It has its own SSA-based backend, with its own optimization passes and its own instruction selection for each supported architecture. The usual reaction is that this must be a mistake — LLVM optimizes better — and it is worth being precise about what is actually being traded.

What is given up is peak optimization on the code shapes LLVM has spent two decades tuning: aggressive loop transformations, a mature auto-vectorizer, and the long tail of [[optimization-levels]] work. On numeric kernels the gap is real and measurable, which is exactly why TinyGo, which does use LLVM, exists.

What is bought is compile speed, control and coupling. Compile speed, because LLVM's optimization pipeline is the single largest term in build time for the languages that use it — Rust is the case study, see [[rust-pipeline]]. Control, because the toolchain owns the calling convention and could change it (Go moved from stack-based to register-based argument passing in 1.17 without asking anyone). And coupling, because the compiler must emit exactly what the runtime consumes: precise stack maps at every safepoint so the collector can find pointers, write barriers around pointer stores, a prologue in almost every function that checks whether the goroutine stack needs to grow, and asynchronous preemption support. Those are compiler outputs designed against one runtime, and they are far easier to maintain in a backend you own.

Generics arrived in Go 1.18, and the implementation is neither of the two answers the rest of this module describes. It is not full monomorphization, which would have multiplied compile time and binary size in a toolchain whose whole identity is not doing that. It is not erasure either, since Go has no boxing-everything representation to erase into.

The gc compiler uses *GC-shape stenciling*. Two type arguments share one generated instance if they have the same "GC shape" — the same size, alignment and pointer layout, which is what the garbage collector actually needs to know. All pointer types share a single shape, so []*Foo and []*Bar get one instance between them. Distinct non-pointer layouts get their own: int64 and float64 do not share, because the operations differ even though the size does not.

The parts that genuinely differ per type — which concrete method to call, which type descriptor to use — are passed in a *dictionary*, an extra hidden argument holding that per-instantiation information. So a method call on a type parameter becomes a dictionary lookup and an indirect call rather than a direct one, which is the cost. It is a middle position: much less code than monomorphization, some indirection that monomorphization would not have, and a devirtualization and inlining story that is weaker than either C++ templates or Rust generics on the same code.

A Go build produces a single executable containing the program, the runtime, the garbage collector, the scheduler, and type metadata for reflection. Nothing needs to be installed on the target machine — no interpreter, no shared library, no version-matched runtime. Copy the file and run it, which is why the language spread through container images and command-line tools so quickly: the image can be a scratch base plus one file.

The price is a floor on binary size — a trivial program is a couple of megabytes because the runtime is in it — and the loss of shared-library updates: a fix in a dependency means rebuilding and redeploying every binary that used it, rather than patching one .so. That is a genuine operational trade, and it is the same one [[static-linking]] and [[dynamic-linking]] describe in general.

The exception is cgo. Calling C requires a C toolchain at build time, brings in the platform's C library, and by default produces a dynamically linked binary — so a Go program that uses cgo gives up exactly the property people chose Go for. CGO_ENABLED=0 is the flag that turns it off, and discovering that a pure-Go program suddenly needs libc at runtime is almost always a transitive dependency pulling cgo in.