Atharva Pandey Gopherine

Every Rust developer has been there. You’re implementing something that feels simple. It works in your head. But the borrow checker says no. You try different approaches. More errors. You start adding .clone() everywhere. You wrap things in Rc<RefCell<...>>. You consider unsafe.

Stop. Take a breath. The borrow checker isn’t wrong — your data flow is confused. And there’s almost always a clean restructuring that makes the error disappear.

This lesson is a field guide. Real patterns that fight the borrow checker, and the restructurings that fix them.

When I came to Go from a Java background, I brought some habits with me that made my code worse, not better. The most persistent one was defining an interface for every dependency, regardless of whether there was any realistic chance of substituting an alternative implementation. I wrote UserRepositoryInterface, EmailSenderInterface, LoggerInterface — an entire shadow type system that mirrored every concrete type in the codebase. Every file had a corresponding interface file. The codebase was twice as large as it needed to be and no easier to test.

You know that moment when a function signature gets so long it wraps three times in your editor and you can’t even find the return type? I hit that wall writing a generic cache layer that needed Hash + Eq + Clone + Debug on the key, Serialize + DeserializeOwned + Clone on the value, and Display on both. The inline bounds turned my function signature into an unreadable mess.

I did not think much about hashing until I had to explain why a cache cluster was unusable after we added two new nodes. We had doubled the cache hit rate over six months, added two boxes to handle the load, and immediately destroyed most of our cached data. Every key rehashed to a different server. Cache hit rate dropped from 85% to under 10%. We were hammering the database.

Refactoring is the one activity that makes codebases better without adding features — and it’s also the activity most likely to introduce bugs if done carelessly. I learned this the hard way on a payments service where I renamed a function, ran the tests, saw green, deployed, and watched a webhook handler silently stop processing because it had been calling the old function name through a string-based registry I hadn’t touched. The tests were green because the old function still existed — I just hadn’t deleted it yet. The refactor was correct; the process was not.

I used to write tests the way I wrote the first functions I ever wrote in Go — flat, repetitive, and with names so generic that when they failed, I had no idea which case broke. “TestParseDate failed” is not information. It’s a dare. Go figure out which of the twelve implicit cases in the body is responsible. I wasted hours doing exactly that before I committed to subtests.

t.Run is one of those language features that looks like a small convenience and turns out to be load-bearing for any serious test suite. Once you start using it, you wonder how you ever shipped anything without it.

We pushed a production incident fix at 3am — rotated to a new IP address for a critical service, updated the DNS record, set the TTL to 60 seconds. Thirty minutes later, half our users were still hitting the broken server. The other half were fine. We had updated the DNS record correctly. The TTL had expired. Yet somehow, stale answers were persisting. That night taught me more about DNS than any documentation had.

I once wrote a generic function that looked perfectly reasonable — accepted any T, did some work, returned a result. It compiled. Then I tried to actually use it with a type that didn’t have Clone, and suddenly the compiler was screaming at me with errors pointing at the function internals rather than the call site. That’s backwards. The fix? Trait bounds. Declare what you need upfront so the errors land where they belong.

Pin is the concept that makes experienced Rust developers pause. Not because it’s inherently complex — it’s actually a pretty small API — but because understanding why it exists requires connecting several ideas: self-referential structs, async/await desugaring, and move semantics.

I struggled with Pin for months. Then I understood what async does under the hood, and Pin suddenly made perfect sense. So that’s how I’m going to explain it.

The Setup: What Async Really Does

When you write an async function:

The first production Go service I wrote hammered our database proxy with thousands of new TCP connections every minute. The proxy started refusing connections. The on-call engineer thought it was the database. It wasn’t. It was me — specifically, my decision to create a new http.Client on every request and then never read the response body to completion. I spent three hours debugging what turned out to be two lines of misunderstood standard library behavior.