What is the difference between GOPATH mode and Go modules?

Question

Accepted Answer

All Go code must live under $GOPATH/src/ No versioning — go get always fetches the latest commit No reproducible builds — different developers could get different dependency versions Cannot have multiple versions of the same dependency Effectively deprecated — only use for very old codebases go.mod declares module name, Go version, and direct dependencies with versions go.sum contains cryptographic hashes for all dependencies — guarantees reproducibility Module proxy (proxy.golang.org) caches modules — works even if the original repo is deleted Private modules: set GONOSUMCHECK and GOMODCACHE for internal packages Minimum version selection (MVS): Go always picks the minimum satisfying version, not the latest module github.com/myorg/myservice

go 1.22

require (
    github.com/gin-gonic/gin v1.9.1
    github.com/jackc/pgx/v5 v5.5.0
    go.uber.org/zap v1.26.0
)

require (
    // indirect dependencies
    github.com/jackc/pgpassfile v1.0.0 // indirect
)

// Replace directive for local development
replace github.com/myorg/shared => ../shared

// Key commands:
// go mod tidy    — remove unused, add missing dependencies
// go mod vendor  — copy dependencies to vendor/ directory
// go mod download — download all modules to cache

What is the difference between GOPATH mode and Go modules?

GOPATH required all Go code to live in a single workspace directory with no versioning. Go modules introduced go.mod for explicit versioning, reproducible builds, and support for any directory structure.

Scenario Questions

Follow-up Questions