Atharva Pandey Gopherine

Rust’s ownership model says every value has one owner. But what happens when multiple parts of your program genuinely need to own the same data? Trees with shared nodes. Graphs with cycles. Observer patterns. Caches shared between subsystems.

Single ownership doesn’t fit everything. Rc and Arc are Rust’s answer — reference-counted smart pointers that enable shared ownership with deterministic cleanup.

The Problem: Multiple Owners

// This doesn't work — who owns the shared config?
struct ServiceA {
    config: AppConfig,  // owns it
}

struct ServiceB {
    config: AppConfig,  // also owns a copy? expensive clone
}

You could pass references, but then you’re dealing with lifetimes everywhere. And if the config needs to outlive any individual service, you need 'static or owned data.

I spent two years writing Go before generics shipped in 1.18, and I’ll be honest — I didn’t miss them at first. Go’s simplicity felt like a feature. Then I found myself maintaining a codebase with six nearly-identical sort functions, a MinInt, MinFloat64, MinInt64, and a comment that said “do not touch, generated.” That’s when I started caring.

Generics in Go aren’t a revolution. They’re a targeted fix for a specific, real pain point: you had to either use interface{} and lose type safety, or repeat yourself across every concrete type you cared about. Neither option aged well.

I spent about six months being wrong about GraphQL. My first exposure to it was a rewrite pitch from a frontend engineer who was tired of making five REST calls to assemble one screen. “GraphQL solves this,” they said, and the demo looked compelling. A single query, exactly the fields you need, one round trip. I was sold before thinking carefully about what we were buying.

The rewrite happened. It took eight months instead of four. Some of the problems we were trying to solve got better. Others got worse. Looking back, the mistake wasn’t choosing GraphQL — it was not being rigorous about where GraphQL actually wins and where it doesn’t before committing.

The first production security incident I dealt with involved a simple integer field in a JSON body. The client sent a negative number where we expected a positive quantity. We hadn’t validated it. The result was a negative charge on a purchase — we were effectively paying customers money. That taught me more about input validation than any security course.

Every byte that arrives over the wire is adversarial by default. Not because every user is malicious, but because your assumptions about the data are not enforced by anything except your own code. HTTP gives you a byte stream. JSON decoding gives you Go values. Neither of those steps checks whether the values make sense for your business logic. That job is yours.

Your startup ships, gains traction, and one day your database becomes the bottleneck. Queries slow down. CPU spikes. The single machine hosting your Postgres instance can’t keep up. This is one of the most predictable problems in engineering, yet I’ve seen teams reach it completely unprepared because they’d never thought carefully about how databases scale. The right solution depends entirely on whether you’re read-heavy or write-heavy, whether your data is relational or not, and whether your workload is even or spiky.

Rust’s borrowing rules say you can’t mutate through a shared reference. Period. Except — sometimes you need to. Caching, reference counting, lazy initialization, mock objects in tests. Legitimate use cases where the “no mutation through &T” rule is too restrictive.

Interior mutability is the escape hatch. It moves the borrow check from compile time to runtime. And yes, it can panic if you get it wrong. That’s the tradeoff.

The Problem: Mutation Through &self

You’re building a struct with a method that logically doesn’t modify the struct’s public state but needs to update some internal bookkeeping:

I have written for i := 0; i < n; i++ so many times that my fingers type it on autopilot. The three-clause for loop is fine — it works, everyone understands it, and Go has always had it. But when Go 1.22 shipped for i := range 10, I stopped and stared at it for a moment. Not because it was complicated. Because it was so obviously the right thing that I wondered why it had taken this long.

I used to use “event” and “command” interchangeably. A message is a message, right? Then I started debugging an event-driven system where the payment service was publishing ProcessPayment events, the order service was publishing CreateShipment events, and two teams were arguing about who owned the workflow. The problem was naming: they were publishing commands disguised as events. The distinction isn’t pedantic — it determines who owns the workflow and how the system evolves.

I have refactored a lot of Go codebases — my own included. And the single most common structural mistake I see is the utils package. Or helpers. Or common. Or sometimes the worst offender of all: a package named after the entire application domain with fifty unrelated files sitting inside it. When I first started writing Go seriously, I made all of these mistakes. This lesson is about why package boundaries matter and how to get them right.

Every Rust developer eventually tries to build this: a struct that owns some data AND holds a reference into that data. It seems perfectly reasonable. It’s also the single thing Rust refuses to let you do safely — and for very good reasons.

I wasted two days on this in my second month of Rust. Let me save you those two days.

The Desire

You want a struct like this: