Prelude-The Philosophy Behind the Syllabus¶

Sit with this document for an evening before week 1. The rest of the curriculum is mechanically dense; this is the only chapter where we step back and define the shape of the discipline.

1. Go Is a Runtime, Not a Language¶

The most damaging misconception a Go engineer can hold is that "Go is just C with garbage collection and goroutines." A working master-level practitioner thinks the inverse:

Go is a runtime-a sophisticated user-space scheduler, allocator, and concurrent garbage collector-that ships with a small, deliberately under-featured language attached.

Almost every interesting performance bug in production Go has its root in the runtime, not in the language semantics. Almost every elegant high-throughput Go architecture is a thin layer over runtime primitives (runtime.Gosched, runtime.LockOSThread, runtime/pprof, runtime/trace, runtime/debug.SetGCPercent, debug.SetMemoryLimit).

Internalize this and the rest of the curriculum makes sense.

2. The Five-Axis Cost Model¶

A working Go engineer reasons about every line of code along five axes simultaneously:

Axis	Question to ask
Allocation	Does this escape to the heap? Could it stay on the stack?
Scheduling	Will this goroutine block? On what-channel, syscall, lock, network? Will it preempt the P?
GC pressure	How much live data does this add? How long-lived? Pointer-rich?
Concurrency safety	Is this aliasable across goroutines? Is the access pattern visible to the race detector?
Failure	What happens on `panic`? On `context.Canceled`? On a deadlocked send?

Beginner courses teach axis 4 only (and incompletely). This curriculum forces all five into your hands by week 12.

3. The "Go Way"-Aesthetic as Engineering Constraint¶

Go's design ethic is, famously, "simplicity." That word is doing more work than newcomers think. Specifically:

Composition over inheritance. Embedding, not subclassing. Interfaces are implicitly implemented; consumers define interfaces, not producers.
Errors are values. No exceptions. if err != nil is not boilerplate-it is a deliberate choice to make every failure path local and visible.
Concurrency by communication. "Don't communicate by sharing memory; share memory by communicating." Channels first, mutexes when channels would obscure intent.
The stdlib is the framework. net/http, encoding/json, database/sql, context, `log/slog - together they cover ~80% of any service. Reach for third-party only when stdlib runs out.
Tooling is part of the language. gofmt, go vet, go test -race, go test -fuzz, pprof, trace. A Go engineer who does not know these is half-trained.

If you fight these defaults, you will fight the language. If you internalize them, you will write code that any other Go engineer can pick up in under a day. That is the actual deliverable Go optimizes for.

4. The Reading List¶

These are referenced throughout the curriculum. You are not expected to read them cover-to-cover before starting; they are pinned tabs.

Primary - The Go Programming Language (Donovan & Kernighan). The canonical text. - 100 Go Mistakes and How to Avoid Them (Teiva Harsanyi). The single best second book. - Concurrency in Go (Katherine Cox-Buday). Read once at week 9, again at week 12. - The Go Memory Model-go.dev/ref/mem. Normative spec for memory ordering. - Effective Go + the Go Code Review Comments wiki-both ~30 minutes of reading, both load-bearing for code-review fluency.

Runtime & internals - The runtime source itself: src/runtime/proc.go (scheduler), src/runtime/mgc.go (GC), src/runtime/malloc.go (allocator), src/runtime/stack.go, src/runtime/chan.go, src/runtime/iface.go. Treat these as primary literature, not reference. - Go internals by jhh.io and Russ Cox's "research.swtch.com" archive. Particularly Go's Work-Stealing Scheduler and The Tricolor Garbage Collector. - Dmitry Vyukov's writings on the scheduler (Vyukov co-designed the work-stealing scheduler). - Madhav Jivrajani's GoTeam talks ("Go scheduler: a deep dive").

Distributed systems canon (not Go-specific, but mandatory) - Lamport, Time, Clocks, and the Ordering of Events. - Diego Ongaro, In Search of an Understandable Consensus Algorithm (the Raft paper). Read in week 21. - Brewer, CAP Twelve Years Later. The original CAP paper is famously misread; this is the cleaner statement. - Kleppmann, Designing Data-Intensive Applications. Read chapters 5–9 in the back half of the curriculum.

Adjacent canon - Drepper, What Every Programmer Should Know About Memory. Re-read in week 5. - Herlihy & Shavit, The Art of Multiprocessor Programming, chapters 7, 9, 13.

5. Curriculum Philosophy: "Read the Source, Ship the Lab"¶

Three rules govern every module:

Source first, blog second. When the curriculum says "study the channel send path," it means open src/runtime/chan.go and read chansend1. Blogs go stale; commits are dated.
One lab per concept, one CL per phase. By the end of each month, the reader has produced one open-source-quality artifact (module, gist, or upstream contribution)-not a notebook of toy snippets.
The race detector and pprof are the teachers. When you do not understand why a program misbehaves, the first response is go test -race, the second is go tool pprof, and only the third is to ask another human.

6. What Go Is Not For¶

A graduate of this curriculum should be able to argue these points in a design review without sounding ideological:

CPU-bound numerical code. No SIMD intrinsics in the language; the compiler's autovectorizer is conservative; the GC tax is non-zero. Use Rust, C++, or call out to BLAS/LAPACK via cgo.
Hard-real-time systems. GC pauses are short but non-zero. Audio DSP, motor control, kernel drivers-wrong tool.
Heavy generic-numeric libraries. Generics landed in 1.18 but have constraints (no method-on-type-parameter dispatch, no specialization). This is fine for collections; it is awkward for `numpy - equivalent libraries.
Code where the team will demand inheritance hierarchies. Go has no inheritance. A team that resists composition will fight Go forever.

The signal that Go is the right tool: you have a concurrency, deployability, and team-onboarding-speed constraint that ranks above raw CPU efficiency or expressiveness.

7. A Note on AI-Assisted Workflows¶

Modern Go authors use LLM tooling. Three rules:

**Never accept generated concurrent code without - race.** The most common failure mode of generated Go is plausible-looking but racy patterns (closing a channel from multiple goroutines, reading amap` from one goroutine while writing from another).
Verify generated interface satisfaction. Models hallucinate methods. Always compile.
Treat suggested context-handling skeptically. The most common context bug-capturing the request ctx in a goroutine that outlives the request-is endemic in generated code.

You are now ready for Week 1. Open 01_MONTH_RUNTIME_FOUNDATIONS.md.