Go for CLI Tools

I wrote drive-downloader to bulk-pull files from Google Drive. The original plan was Python - I know the Drive API from other projects, and the client library is good. But the intended users were non-devs on different machines. Distributing a Python script means telling people to install Python, create a venv, pip install the dependencies, then run it. That's a support ticket waiting to happen.

Go compiles to a single static binary. Copy it to /usr/local/bin and you're done. No runtime, no dependencies, nothing to install. Cross-compilation is built into the toolchain:

GOOS=linux GOARCH=amd64 go build -o drive-downloader-linux ./cmd/main.go
GOOS=darwin GOARCH=arm64 go build -o drive-downloader-macos ./cmd/main.go
GOOS=windows GOARCH=amd64 go build -o drive-downloader.exe ./cmd/main.go

Three commands. Three binaries. Works on every target without touching those machines.

The stdlib is surprisingly complete for CLI work. flag for argument parsing, os and io for file handling, net/http for the OAuth flow, encoding/json for parsing API responses. I didn't pull in a single third-party package for the core functionality - only the Google API client library, which was unavoidable.

One thing that's genuinely annoying: error handling verbosity. Every function returns (result, error) and you write if err != nil { return err } constantly. In a complex tool this adds up fast. I got used to it, but coming from Python it feels repetitive in a way that's hard to explain until you've written it a few hundred times.

This isn't an "always use Go" post. For scripts I run myself, Python is faster to write and iterate on. For a project where I need to send a binary to someone and have it just work - no setup, no version mismatches, no "what Python are you running" - a static binary is worth the verbosity.

The boring reason I picked Go over Rust for this: I already knew Go.