Atharva Pandey Gopherine

The first time I needed to profile a Go service in production, I assumed I’d have to deploy a special build, reproduce the problem locally, or use some heavyweight APM product. Then I learned that Go’s net/http/pprof package can serve live profiling data from a running process via HTTP — in a container, in Kubernetes, right now, without redeployment.

pprof is the built-in Go profiler. It can capture CPU profiles (what functions are consuming CPU time), heap profiles (what’s allocated in memory and by whom), goroutine profiles (how many goroutines exist and what they’re doing), and block/mutex profiles (where goroutines are waiting). All of this is available as HTTP endpoints that you can scrape with go tool pprof from your laptop.

I once opened a file called app.rs and found a struct with forty-two fields. Forty-two. It held the database connection, the HTTP client, the cache handle, the logger, the config, the metrics collector, the rate limiter, the auth provider, the feature flags, the email sender, the template engine, and about thirty other things I’ve blocked from memory. Every function in the codebase took &self on this monster. Need to send an email? You need the god struct. Parse a config value? God struct. Log a message? Believe it or not, god struct.

I’ve spent time in this series showing you how to make Go programs faster — escape analysis, stack allocation, pre-sizing data structures, zero-copy string handling, benchmarking discipline, pprof profiling, CPU vs memory tradeoffs. Every technique is real and useful. And every single one of them has been misapplied, including by me, when applied before understanding whether they were needed. The last lesson isn’t another technique. It’s the discipline that makes all the other techniques worth using: measure first, understand where the actual cost is, and optimize only there.

I inherited a Rust codebase once where the entire state machine was driven by string comparisons. The order status could be "pending", "processing", "shipped", "delivered", or "cancelled". Except sometimes it was "Pending" with a capital P. And there was one code path that set it to "canceled" — one L, American spelling. And another that used "CANCELLED". The bug lived in production for weeks because nobody could figure out why some orders were getting stuck in a phantom state that didn’t match any of the if status == "cancelled" checks scattered across thirty files.

After spending several lessons on what reflection can do, it is worth turning the question around: when should you specifically choose not to use reflection, even when it would work? The answer is almost always “when you have a statically typed alternative,” because statically typed code is faster, catches errors at compile time rather than runtime, and is easier for both humans and tools to reason about.

Go 1.18 added generics, which eliminated one of the most common justifications for reflection: writing algorithms that work on slices, maps, or other containers of unknown element type. Code generation eliminates another: producing type-specific serializers, converters, and mappers that are faster than reflection can ever be. Knowing when to reach for these alternatives instead of reflection is part of writing mature Go.

A service I was responsible for went down at 2 AM on a Saturday because of a single .unwrap() call on line 847 of a file nobody had touched in months. The function parsed a config value that was supposed to always be present. Somebody changed the config format in a different repo, the value became optional, and that .unwrap() detonated like a landmine — thread 'main' panicked at 'called Option::unwrap() on a None value'. Down. Dead. Pager screaming.

I shipped a “hello world” Rust binary to a team once and they came back confused: “Why is this 4 megabytes?” Fair question. A C hello-world is 16KB. A Go hello-world is about 2MB. A default Rust hello-world with standard linking is 3-4MB.

That 4MB isn’t wasted — it’s the Rust standard library, panic handling, formatting machinery, and debug symbols. But when you’re building container images, deploying to embedded devices, or targeting WebAssembly, every megabyte counts. Here’s how to cut Rust binaries down to size.

Here’s a mistake I see in almost every Go codebase written by people coming from Java or C#: they accept concrete types everywhere and return interfaces from constructors. It feels “enterprise-y”. It’s actually backwards. The idiomatic Go version is the opposite — accept the smallest interface that does the job, return the richest concrete type you have.

The Problem

Most of the pain comes from accepting concrete types. Once you lock a function to a specific concrete type, every caller that doesn’t have exactly that type is stuck. Tests become integration tests. Swapping implementations requires rewriting functions. And the function itself becomes harder to compose.

Nobody tells you that the first goroutine you “fire and forget” in production is the one that eventually takes down your service at 3 AM. You start it, it runs, and everything looks fine — until requests pile up, memory climbs, and your dashboards turn red because five hundred goroutines are blocked waiting on a channel that’ll never receive another value. The problem isn’t that goroutines are dangerous. It’s that nobody taught you to think about who owns them.

I was reviewing a pull request last year from a developer who’d been writing Rust for about three months. The code compiled. The tests passed. Everything looked fine — until I ran grep -c '\.clone()' src/ and got back a number that made me physically uncomfortable. Forty-seven clones across six files. The codebase was a data pipeline processing millions of events per hour, and this person had turned every ownership error into a .clone() call until the compiler stopped yelling.