Go Modules - Package Management for Go

Before modules, Go had this weird requirement where all your code had to live under one specific directory tree. Not just your current project - everything. Your personal projects, work stuff, random tutorials - all crammed into $GOPATH/src/github.com/whoever/whatever.

I've onboarded maybe 20 developers over the years. Every single fucking one got confused by GOPATH. It's like explaining why we used to store files on floppy disks - technically it worked, but who thought this was a good idea?

The Old Nightmare

GOPATH forced this rigid directory structure that made no sense to anyone. Want to work on two projects that need different versions of the same library? Nope, not happening. You got one version of everything, globally.

Import paths had to match the directory structure exactly. Watched a developer spend an hour debugging because they cloned a repo to their Desktop instead of the magical GOPATH location. The compiler just said "can't find package" - no hint about GOPATH, no suggestion about directory structure, nothing useful.

New developer onboarding always went the same way:

1. "Why won't my code compile?"
2. "Did you set up GOPATH?"
3. "What's GOPATH?"
4. Me explaining why Go decided to reinvent directory organization

The worst part? Explaining to someone coming from Python or Node.js why they couldn't just put their project wherever made sense.

Modules: How It Should Have Been From Day One

Run go mod init in any directory and you're done. No special folder structure, no environment variables, no explaining to junior developers why their perfectly reasonable file organization is wrong.

go.mod tells Go what you need:

module myproject

go 1.23

require github.com/gin-gonic/gin v1.9.1

go.sum contains checksums for everything:

github.com/gin-gonic/gin v1.9.1 h1:4idEAncQnU5cB7BeOkPtxjfCSye0AAm1R0RVIqJ+Jmg=

Run go mod tidy and Go downloads everything to a shared cache in your home directory. Your project folder stays clean - no giant node_modules directory eating disk space. If the checksums don't match, Go refuses to install anything. Simple and secure.

Minimal Version Selection (Because Latest != Best)

Here's where Go got it right: it doesn't automatically update everything to the newest version like npm does.

If your project needs library A v1.2+ and another dependency needs A v1.4+, Go uses v1.4. Not v1.9 that came out yesterday and might break everything.

This prevents those fun Monday mornings when your build suddenly shits the bed because someone released a "minor" update that changed the API. Had a React project break production because react-router 6.4.1 to 6.4.2 changed how location state worked - "patch" release, my ass.

The Go team's MVS design is predictable and boring. When you're trying to ship features instead of debugging dependency conflicts, boring is exactly what you want.

No Configuration Bullshit

Maven has XML files longer than most novels. npm has package.json files with more scripts than a Hollywood production. Python has requirements.txt files that drift out of sync with reality.

Go modules: run go mod init and start coding. That's it.

The go.mod file starts with 3 lines and only grows when you actually add dependencies. No build scripts, no bundler configuration, no wondering why your coworker's laptop builds successfully but yours doesn't.

Downloads That Don't Make You Take Coffee Breaks

Go downloads are fast. CI that used to take 12 minutes for npm install now does the entire Go build in under a minute. Helps that Go downloads happen in parallel and hit the module proxy instead of hundreds of different GitHub repos.

Docker images stay small too. Go binary in Alpine is 15-25MB depending on what you're doing. Node.js base image is 180MB before you add a single dependency.

Your Hard Drive Won't Hate You

npm drops a node_modules folder in every project. Each one is hundreds of megabytes of duplicate dependencies. Go uses a shared cache in your home directory.

Multiple projects using the same library? One copy. Not fifty fucking copies scattered across your laptop consuming all available disk space.

I've cleaned up 20GB+ of node_modules folders from developer laptops. My Go dependency cache is tiny compared to that bullshit.

Security That Actually Prevents Problems

Every dependency gets checksummed in go.sum. If those bytes don't match exactly, Go won't use it. Simple.

npm audits vulnerabilities after installing packages. Go validates checksums before downloading anything. When the left-pad incident happened in 2016 and broke half the JavaScript ecosystem, Go users didn't even notice. The module proxy and checksum verification meant if you already had a version cached, you kept using that exact code.

Monorepos Without the Nightmare

JavaScript monorepos require Lerna, Yarn workspaces, or some other complex setup that breaks every few months.

Go workspaces: create a go.work file with the modules you want to work on together. Done.

go 1.23

use (
    ./api
    ./worker
    ./shared
)

That's literally it. No hoisting magic, no symlink hell, no wondering why your imports randomly broke.

Versioning That Makes Sense

Major version changes require new import paths:

import \"github.com/lib/pq\"     // v1.x
import \"github.com/lib/pq/v2\"  // v2.x

Breaking changes can't sneak in through dependency updates. Your code either compiles or it doesn't. No runtime surprises when some library decides to change their API in what they call a "patch" release and you find out at 3am when prod starts puking 500s everywhere.

The Practical Benefits

Go modules solve the annoying problems that eat your day:

• Builds work consistently across machines
• Dependencies don't vanish from the internet
• Security issues get caught at build time
• Deployment is copying one executable file

Netflix, Spotify, and basically every cloud provider uses Go for infrastructure tooling. When your software runs production systems globally, you can't mess around with flaky dependency management.

What Still Annoys Me

Go modules don't solve everything. Error handling is still verbose. The learning curve is real if you're used to just running npm update on everything.

Some edge cases with replace directives can trip you up. Private modules need authentication setup that's not always obvious.

But for dependency management specifically? Go modules cause way fewer problems than the alternatives. They're predictable and boring, which is what you want when you're trying to build features instead of debugging package managers.