Chapter 3
What separates Go
Interfaces, errors, concurrency, generics, testing.
By the end of this chapter you'll be able to
- The mechanical part
- The direction: interfaces belong to the consumer
- Keep them small
- The empty interface, and `any`
- The nil interface trap
Lessons
Module: What separates Go
Interfaces, and why Go's point the other way
If you take one idea from this book, take this one.
Designing with errors: what a package should return
Chapter four covered the mechanics: if err != nil, wrapping with %w, errors.Is and errors.As.
defer, panic and recover
Three keywords that look like finally, throw and catch and are not.
Goroutines, against the event loop
You already write concurrent code.
Channels, and the select statement
Goroutines run independently.
sync: mutexes, and when a channel is the wrong tool
The previous chapter sold channels.
Context: cancellation, deadlines, and request scope
You will see ctx context.Context as the first parameter of almost every function in a Go codebase, and it looks like noise until you understand.
Generics, briefly and honestly
Go got generics in 1.18, after a decade of arguing about whether it should.
Testing: the runner is already installed
Go ships a test runner, an assertion-free testing philosophy, a benchmark harness, a coverage tool, a fuzzer and a race detector.
JSON, struct tags, and the capital letter that bites
JSON is where your Go backend meets your React frontend, so this chapter earns its place twice: once now, and again in part four when Grit.
Chapter assignment
Finish every assignment in What separates Go
Each lesson in this part ends with its own assignment, named for the leaderboard. Finish them in order.
See success criteriaLesson 1 takes ~15 min.
Start chapterSpot a typo? Have an idea?
Help us improve this chapter. One click opens a GitHub issue with this chapter's URL pre-filled — suggest a clearer wording, report a bug, or request a new lesson. The course keeps improving thanks to learners like you.
Suggest an improvement on GitHub