Modules

go.mod: dependencies and the module path

A module is Go's unit of dependency versioning — one go.mod file at the root of a project, declaring the module's own import path and every external package it depends on:

go mod init myproject

produces:

module myproject
 
go 1.23

Add a dependency by importing it in code and running:

go get github.com/some/package
go mod tidy

go get fetches the package and records the exact version in go.mod; go mod tidy reconciles go.mod (and the generated go.sum, which pins exact checksums) with what your code actually imports — adding anything missing, removing anything unused. This is the closest Go equivalent to Python's requirements.txt/pyproject.toml, except versions and checksums are locked automatically rather than being something you maintain by hand.

Standard library packages need no module at all

Everything you've imported so far — fmt, sync — ships with the Go toolchain itself and needs no go get, no entry in go.mod, nothing beyond the import line. The standard library is large and used constantly in idiomatic Go; reaching for a third-party package for something the standard library already does well (HTTP servers, JSON encoding, string manipulation) is often considered unidiomatic rather than pragmatic, the opposite of the instinct in some ecosystems.

A minimal project layout

myproject/
  go.mod
  main.go
  shapes/
    rectangle.go
    circle.go

Nothing here is enforced by the compiler beyond "each directory is one package" — but this shape (a main.go at the root, feature code split into subdirectory packages) is what you'll see in the overwhelming majority of real Go projects, including the standard library's own source.