Why I write my server tools in Go

When a tool has to run on a client's server, the fewer moving parts the better. Go gives me one binary instead of a language runtime, a virtual environment, and a lockfile.

Static binaries are a superpower

CGO_ENABLED=0 go build produces a single file that runs on any Linux box with the same architecture. No pip install, no Node version, no "works on my machine." I copy it, chmod +x, and it runs.

Cross-compiling costs nothing

Building for a different OS or architecture is an environment variable away:

GOOS=linux GOARCH=amd64 go build ./cmd/monitor

That means I can build a Linux binary from my laptop without setting up a matching VM.

Deploys are one file

There's no dependency tree to audit at deploy time. The binary either runs or it doesn't. Rollbacks are just keeping the previous file.

What Go doesn't do

Go isn't the shortest code for every job. For quick shell glue, a Bash script still wins. But the moment a tool needs flags, structured output, or to be handed to someone else — Go pays for itself.

The tradeoff is verbosity, and I've decided it's worth it for anything that touches production.