im·a·cto
← choices

$ cat choices/go.md

Go

the call

I reach for Go when the workload is heavy IO or concurrency and the language I'm already in is the wrong tool for it. I don't rewrite a healthy service in Go for sport.

why

Go does one thing better than almost anything: move a lot of bytes with very little overhead. Cheap goroutines, tight memory, a runtime built for IO. When a process is fighting its own language to do the actual job, that’s not a tuning problem. It’s a tool problem.

when I don’t

Go is a scalpel, not a kitchen. If the team’s productive in what they’ve got and the workload fits, switching languages to chase a benchmark is résumé-driven development. The cost of a second language in the stack is real: hiring, context-switching, ops. It has to pay for itself in the part of the system that actually hurts.

in production

At Brandfolder, Ruby was crashing while generating large zip files, the wrong runtime for that much IO. The easy move was to throw bigger machines at it. Instead we carved out just the zip pipeline and built it in Go, delivering multi-gigabyte archives at minimal resource cost while the rest of the app stayed Ruby. Right tool for the one part of the system that needed it. Not a rewrite, a scalpel.— see: works / Brandfolder

the principle under it

This is the whole job in miniature: diagnose the actual bottleneck, then reach for the tool that fits it. Not the one you already know, and not the one that looks impressive. Most “we need to rewrite” instincts are really “we haven’t found the one piece that’s actually broken.”

the gaps — what it costs even when it’s right

A second language is a permanent tax. Every Go service is now something a Ruby- or Elixir-shaped team has to hire for, context-switch into, and keep in their heads. Worth it for the zip pipeline; not worth it for a CRUD endpoint.

Rewrite creep is real. Once Go is in the stack and it’s fast, there’s pressure to keep reaching for it. The discipline is to keep it confined to the parts that actually need it, not let it sprawl.

Error handling is verbose and the ecosystem is thinner than the batteries-included worlds. You trade developer ergonomics for runtime performance: a fine trade for hot paths, a bad one for the 80% of code that isn’t hot.

© 2026 — written by a human, with help, and said so canonical jasonwaldrip.com · delivered through The Bushido Collective