why I reach for Go

Go is my default for backend services. Not because it is the most exciting language I know — it is not — but because it is the one that wastes the least of my time between "I understand the problem" and "it is running in production for real users." This post is about why I keep reaching for it.

01 the speed-to-production argument

The unit I measure is not lines of code per hour. It is days until a new service is serving real traffic, with telemetry, behind an auth boundary, on a schedule a team can operate. On that axis Go wins most comparisons I care about.

Standard library covers the ninety percent case. net/http is enough for almost any API I have built; I have not reached for a web framework in years. The toolchain is one binary. The binary itself is a single artifact I can drop into a container and stop thinking about.

hemepulse is the shape of what I mean. A Go 1.26 API on plain net/http, a strict middleware chain, property-based tests, and an OTel collector — the boring parts right on day one. The interesting product work starts the day the scaffolding lands.

02 where Go loses

Go is the wrong choice when the value of the service is in the type system. If you need algebraic data types, exhaustive pattern matching, or a compiler that forces you to handle every variant of an enum, Go will frustrate you. I have shipped Go services where the runtime complexity was "one switch statement that was missing a case" and the bug lived in production for a week. That is the failure mode.

It is also the wrong choice when the hot path is throughput-sensitive enough that garbage collection pauses show up in tail latency. Go's GC is good; it is not invisible. When I need predictable tail latency under load, I go to Rust. Why I reach for Rust is the other half of this argument.

03 the healthcare fit

Most of the regulated-industry work I do ends up in Go. Part of that is GCP — ADK, Vertex, Pub/Sub, the healthcare APIs all have first-class Go clients, and the operational posture (structured logs, explicit error handling, context propagation) matches what auditors want to see.

Part of it is cultural. A Go codebase is readable by any backend engineer inside a week; that matters when the team rotates and the legal team is reading diffs. I have handed off Go services to teams that were nominally Python shops and watched them become productive without a language-retraining project.

code-review-go is built on Google's Agent Development Kit, which is a Go-native agent framework. The ParallelAgent + LoopAgent pattern is just goroutines with structure around them. If you already know Go, you already know ADK.

04 what I stop optimizing

Go forces a kind of taste by refusing to give you clever tools. You cannot write a three-line monad-transformer chain in Go, so you do not. You write the explicit thing. That explicit thing is usually the thing you would have wanted to read six months later anyway.

The things I stop optimizing in Go:

• Error handling elegance. if err != nil { return fmt.Errorf("doing X: %w", err) } is verbose. It is also the clearest trace I have ever read at 2am.
• Abstraction layers. I write the concrete thing. If three concrete things turn out to share shape, I extract. Usually they do not.
• Type gymnastics. Generics exist now. I use them for collections and rarely for anything else.

05 when I reach for Rust instead

The decision boundary is usually cost. If the service is going to carry real traffic for years, if every wasted millisecond is a line item on a bill, or if I am shipping a library that downstream code has to vendor — that is Rust territory. Why I reach for Rust covers the specifics.

Everything else is Go. The question I ask at the start of a new service is will Go cost me anything I will notice in a year? If the honest answer is no, then reaching for anything else is paying a complexity tax for aesthetics.

Go is not exciting. That is the feature.