Atharva Pandey Gopherine

Every time I see reflection in a hot path, I know there is a performance conversation waiting to happen. Reflection in Go is not arbitrarily slow — it is predictably and measurably slow in specific ways. Understanding those costs, benchmarking them in your context, and knowing the standard mitigation patterns (primarily caching) lets you use reflection where it belongs without making your application noticeably slower.

The performance story of reflection has two parts: the cost of type inspection (getting a reflect.Type, reading fields, checking kinds) and the cost of value operations (getting a reflect.Value, reading or setting field values, calling methods). Type inspection is expensive the first time and cheap if cached. Value operations are expensive every time and there is no way to avoid that cost except to reduce how often you do them.

I once read the docs for a popular Rust crate, copied the example verbatim, and it didn’t compile. The API had changed two versions ago but nobody updated the docs. I spent twenty minutes debugging code that was supposed to be the “getting started” guide. Rust has a built-in solution to this exact problem, and it’s one of the most underappreciated features in the language.

The Problem

Documentation lies. Not on purpose — it lies because code evolves and docs don’t. A function signature changes, a parameter gets renamed, a return type shifts from String to &str, and the example in the docstring quietly becomes fiction. No compiler warning, no test failure, just a frustrated user copy-pasting broken code.

There’s a specific moment in every senior-level interview loop where the conversation shifts. The system design round wraps up, the coding is done, and then an interviewer leans back and asks something like: “Tell me about a time you had to push back on a product decision you thought was wrong.” Or: “Describe a situation where you disagreed with your tech lead and how you handled it.”

These are not softballs. For companies hiring at senior or staff level, behavioral questions about leadership and conflict are often the deciding signal. Everyone who makes it to that round can code. Not everyone can navigate the organizational and interpersonal dynamics of a senior role. These questions are trying to separate the two.

One of the most common mistakes I see in Go codebases post-1.18 is people reaching for generics when interfaces were already the right tool — and vice versa. The two features look superficially similar. Both let you write code that works with multiple types. But they’re solving different problems, and using the wrong one makes code harder to read, test, and extend.

Here’s the question I ask myself every time: Is what varies the behavior, or the data shape? That single question gets me to the right answer ninety percent of the time.

I was reading about how RocksDB works one evening and kept seeing references to mmap for reads. I had heard of memory-mapped files but thought of them as a niche optimization. Then I realized: SQLite uses mmap. WiredTiger (MongoDB’s storage engine) uses mmap. LMDB is built almost entirely around mmap. Even some Postgres configurations use mmap for WAL. Understanding mmap explains a lot about how high-performance storage works, why some databases are so fast for random reads, and why memory and I/O are so deeply intertwined at the OS level.

A colleague once reviewed one of my Rust libraries and said, “Your unit tests pass, but I can’t actually use the crate — the public API doesn’t compose the way anyone would expect.” He was right. I’d tested every internal function meticulously and completely ignored the experience of someone actually calling my library from the outside. That’s the gap integration tests fill.

The Problem

Unit tests live inside your source files and can access private functions. That’s great for verifying internal logic, but it creates a blind spot: you never validate that your public API actually makes sense. You can have perfect internal functions that combine into a terrible user experience.

When I started writing Go HTTP servers, I thought TLS was someone else’s problem. A load balancer in front of my service handled HTTPS termination, so my service only ever spoke plain HTTP on the internal network. That is a common and often defensible architecture. But it means that if anyone gains access to your internal network — a compromised service, a misconfigured cloud security group, a rogue container — all traffic between your services is plaintext. I learned this lesson not from a breach but from a penetration test report that listed it as a finding with a crisp paragraph explaining exactly why it mattered.

For most of my Go career, the standard library’s net/http.ServeMux was something I used for toy services and immediately replaced with gorilla/mux for anything real. The standard mux could not match HTTP methods. It could not extract path parameters. It matched prefixes in ways that surprised people. The moment a production service needed GET /users/{id} and POST /users, you reached for a dependency.

Go 1.22 changed that. The enhanced ServeMux now supports method matching, wildcard path parameters, and precedence rules that actually make sense. I rewrote three internal services to drop gorilla/mux after reading the release notes, and every one of them got shorter and simpler. This lesson covers exactly what changed and when you still might want a third-party router.

I did 12 months of on-call on a team that hadn’t invested in reliability. The rotation was weekly. In a bad week, I’d get 15-20 pages. A good week was 5. I was exhausted by the end of my shift, and the paging frequency had barely changed over those 12 months. We were fixing incidents, not fixing the causes. The next team I joined approached on-call differently: on-call was treated as a reliability sensor, not a firefighting rotation. Pages were tracked, patterns identified, and root causes fixed. By month 6 I was averaging 2 pages per week on-call. The work we did during on-call made future on-call better.

I shipped a Rust library last year that had zero tests. Not because I’m lazy — I was prototyping, moving fast, “I’ll add tests later.” You know how that story ends. A one-character typo in a boundary check sat in production for three weeks before someone’s data got silently corrupted. Three weeks. I’d have caught it with one assert_eq! and thirty seconds of effort.

Never again. Here’s how testing actually works in Rust, from the ground up.