Reflection on

Lesson 7: go:generate and Code Generation — Let the machine write the boring code

Tue, 10 Jun 2025 00:00:00 +0000

go:generate is Go’s mechanism for attaching arbitrary code generation commands to your source files. It is not magic — it is a convention that tells go generate which commands to run and where. When you run go generate ./..., the tool reads every //go:generate comment in your source tree and executes the commands they reference. What those commands produce is up to you: String() methods for enum types, serialization code, mock implementations, database query functions, or anything else you can express as a code generator.

Lesson 6: Avoiding Reflection — Generics and code generation often win

Tue, 08 Apr 2025 00:00:00 +0000

After spending several lessons on what reflection can do, it is worth turning the question around: when should you specifically choose not to use reflection, even when it would work? The answer is almost always “when you have a statically typed alternative,” because statically typed code is faster, catches errors at compile time rather than runtime, and is easier for both humans and tools to reason about.

Go 1.18 added generics, which eliminated one of the most common justifications for reflection: writing algorithms that work on slices, maps, or other containers of unknown element type. Code generation eliminates another: producing type-specific serializers, converters, and mappers that are faster than reflection can ever be. Knowing when to reach for these alternatives instead of reflection is part of writing mature Go.

Lesson 5: Validation Frameworks — Reflect once, validate everywhere

Mon, 10 Feb 2025 00:00:00 +0000

Input validation is one of those problems that looks solved until you realize you are writing the same type of check — not nil, min length, valid email format, required when other field is set — dozens of times across dozens of handlers. Centralizing these rules without reflection means either a massive switch statement or hand-writing a validation function for every struct in your application. Reflection makes it possible to declare validation rules once, at the struct, and enforce them automatically everywhere that struct is validated.

Lesson 4: Building a Serializer — encoding/json under the hood

Thu, 28 Nov 2024 00:00:00 +0000

encoding/json is Go’s most-used package and one of its most instructive implementations. Under the hood it is almost entirely reflection: it inspects struct field types, reads json tags, handles pointer dereferences, recurses into nested structs, and handles special cases like time.Time and json.Marshaler interface implementations. Building a simplified version of a struct serializer from scratch is the best way to understand both how reflection works in practice and why encoding/json makes the design choices it does.

Lesson 3: Struct Tags — Metadata your compiler ignores but your framework reads

Tue, 08 Oct 2024 00:00:00 +0000

Struct tags are one of Go’s most practically useful metaprogramming tools and one of its least formally documented features. The syntax is simple — a raw string literal after the field type in a struct — but the convention built on top of it powers nearly every serialization library, ORM, validator, and configuration loader in the ecosystem. Understanding how tags work at the reflection level demystifies why encoding/json knows to use omitempty, why database/sql scanners can map column names to struct fields, and how you can build your own tag-driven behavior.

Lesson 2: Performance Costs — reflect.ValueOf is not free

Thu, 15 Aug 2024 00:00:00 +0000

Every time I see reflection in a hot path, I know there is a performance conversation waiting to happen. Reflection in Go is not arbitrarily slow — it is predictably and measurably slow in specific ways. Understanding those costs, benchmarking them in your context, and knowing the standard mitigation patterns (primarily caching) lets you use reflection where it belongs without making your application noticeably slower.

The performance story of reflection has two parts: the cost of type inspection (getting a reflect.Type, reading fields, checking kinds) and the cost of value operations (getting a reflect.Value, reading or setting field values, calling methods). Type inspection is expensive the first time and cheap if cached. Value operations are expensive every time and there is no way to avoid that cost except to reduce how often you do them.

Lesson 1: When Reflection Is Justified — The last resort that sometimes is the only resort

Fri, 28 Jun 2024 00:00:00 +0000

Go’s reflect package carries a reputation: “don’t use it unless you have to.” That advice is correct but incomplete. Understanding when you actually have to use it — and when you are just reaching for it out of habit from dynamic languages — is the difference between reflection that pulls its weight and reflection that creates unmaintainable, slow, panic-prone code that confuses every future reader of the codebase.

Reflection lets Go inspect and manipulate values, types, and struct fields at runtime without static type information. It is the mechanism behind encoding/json, database/sql’s row scanning, struct validators, ORM frameworks, and dependency injection containers. It is also the mechanism behind a lot of code that should have just used a map or an interface.