How to learn Go

You learn the small core of the language — packages, functions, variables, control flow, slices, maps, and structs — plus go build, go test, and gofmt. This sits first because everything else depends on it, but it is deliberately compressed: the syntax is not the hard part.

• Packages and imports
• Functions and multiple return values
• Slices and maps
• Structs and methods
• Pointers and value vs reference semantics
• go build, go run, go test, gofmt
• Error values and the error interface

You can now: Write a small command-line programme that reads a file, counts word frequencies, and prints the top ten, with a test for the counting function.

Goroutines, channels, and select are introduced now, while the language is still fresh, because they are the reason to use Go. You learn the patterns — fan-out, fan-in, worker pools, and cancellation — before you have built up habits from other languages that fight against them.

• Goroutines and the go keyword
• Channels: buffered and unbuffered
• The select statement
• Fan-out and fan-in patterns
• Worker pools
• Context for cancellation and deadlines
• sync.WaitGroup and sync.Mutex

You can now: Build a programme that fetches several URLs concurrently, with a timeout, and prints the first successful response or a clear error.

Go's interfaces are small, implicit, and structural — a type satisfies an interface just by having the right methods. This stage sits after concurrency because you now have real code to refactor, and interfaces are how you make that code testable and decoupled.

• Interface types and implicit satisfaction
• The empty interface and type assertions
• Type switches
• Embedding structs and interfaces
• The io.Reader and io.Writer interfaces
• Testing with interfaces and mocks
• The standard library's small-interface philosophy

You can now: Refactor your URL fetcher so the HTTP client is behind an interface, then write a test that uses a fake client returning canned responses.

You stop writing toy examples and build a real command-line tool, leaning on the standard library rather than third-party frameworks. This stage is where the pieces from earlier stages — concurrency, interfaces, error handling — come together in code you would actually run.

• flag for command-line arguments
• os and os/exec for files and processes
• encoding/json and encoding/csv
• net/http client and server
• bufio for streaming I/O
• log and log/slog for structured logging
• testing with table-driven tests and subtests

You can now: Ship a CLI tool that reads JSON from stdin, processes it concurrently, and writes results to stdout, with tests covering the happy path and at least two error cases.

You return to concurrency with more context, now that you have built real programmes. This stage covers the failure modes — deadlocks, race conditions, goroutine leaks — and the tools for finding them, plus the patterns that avoid them.

• Race conditions and the race detector
• Deadlocks and how to avoid them
• Goroutine leaks and how to find them
• Channel ownership and direction
• The done channel idiom
• sync.Once and sync.Cond
• errgroup for coordinated goroutines

You can now: Take a concurrent programme you wrote earlier, run it under the race detector, and fix at least one real race condition you find.

The final stage is about leaving the tutorial behind. You read substantial Go codebases, learn the idioms that only appear in production code, and make a small contribution. This is where you find out what you actually know and what you have been avoiding.

• Reading the standard library source
• Common project layouts and package naming
• Error wrapping and errors.Is / errors.As
• Generics: when to use them and when not to
• Profiling with pprof
• Writing and reviewing a small patch
• Go modules and dependency management

You can now: Read a 2,000-line Go project you have never seen, explain its concurrency model in a paragraph, and submit a one-line fix or test to an open-source Go project.