Orientation
What the Go runtime and toolchain actually give you, how modules and toolchain selection work, and the habits that make Go code look like Go rather than like translated Java.
3 lessons · 33 min
Print the whole moduleModule objectives
- Describe what a Go build produces and what it does not need at run time
- Explain minimal version selection and predict what go mod tidy will and will not upgrade
- Force an exact toolchain, and use a workspace instead of a replace directive
- Apply Go's naming conventions, including what capitalisation actually controls
- Lay out a module with cmd, internal and library packages
01The runtime and the toolchain
The artefact a build produces, the scheduler and collector inside it, and the module system that decides which compiler and which dependency versions you get.
Print this unit- 1.1What Go actually isGo is a statically typed, garbage-collected language that compiles to one static binary with a scheduler inside it. This lesson sets out the runtime you are buying, the release cadence you are committing to, and the three things about Go that most annoy people arriving from a bigger language.10m
- 1.2Modules, versions and the toolchain that downloads itself`go.mod` is not `package.json` and not `pom.xml`. This lesson covers module initialisation, minimal version selection, the private module path that fails on day one, the toolchain directive that is a floor rather than a pin, and the `tool` directive that replaced the tools.go trick.12m
02Working in Go
One formatting style, capitalisation as the only access control there is, and the project layout a Go reviewer expects to find.
Print this unit