Atharva Pandey Gopherine

Most engineers don’t think of themselves as solving graph problems. They think they’re deploying microservices, resolving package dependencies, routing network traffic, or modeling social connections. But the underlying structure in all of these is a graph, and the algorithms that make those systems work — Dijkstra’s, topological sort, BFS, DFS — are graph algorithms.

Once I started seeing graphs everywhere, I started solving systems problems better. Let me show you the representation, the key algorithms, and the production contexts where this thinking pays off.

I used to write code like point.x, point.y, point.z over and over in the same function. Three fields, three accesses, repeated twelve times. Then I learned destructuring and realized I’d been doing the equivalent of opening a package, looking at each item individually, and putting it back before looking at the next one.

Destructuring is opening the package and grabbing everything at once.

The Problem With Field-by-Field Access

When you work with compound types — structs, tuples, enums with data — you constantly need to pull values out of them. In most languages, this means dot access or method calls, and you end up with verbose code that obscures the actual logic:

There is a saying in the Go community: “cgo is not Go.” It is not an insult. It is a warning. The moment you add import "C" to a file, you are no longer writing a pure Go program — you are writing a Go program that manages a C boundary, and all the things that make Go comfortable (fast builds, easy cross-compilation, the race detector, straightforward stack traces) become harder. You are doing it on purpose, because the alternative is worse.

The best generic code I’ve ever written looks like the worst. No clever type wizardry, no five-level constraint hierarchies — just a function that clearly does one thing, works for any type that makes sense, and disappears into the background of a codebase. When someone reads it two years later and immediately understands it, that’s a win.

This lesson is about the patterns where generics genuinely shine. These are the ones that survived code review, that made the team’s lives measurably better, and that I’d reach for again without hesitation.

Picture this: it’s 2 AM, your pager goes off, and the log says "connection refused". Connection to what? From where? During which operation? That single error message is technically correct and practically useless. I’ve been in that exact situation enough times to develop strong opinions about error context. Every error in a production system should answer three questions: what happened, where did it happen, and what was the system trying to do when it happened.

Without rate limiting, a single misbehaving client can consume all your resources and deny service to everyone else. A bug in a client that retries in a tight loop. A competitor scraping your API. A DDoS attack. A feature that accidentally calls your endpoint ten times per button click. Rate limiting is the mechanism that prevents any of these from taking down your service — it’s the first line of defense between the internet and your origin.

I shipped a Python service once that had a match statement handling four message types. Three months later, the team added a fifth type. Nobody updated the match. The default branch silently swallowed the new messages, and we lost two days of analytics data before anyone noticed.

Rust’s match wouldn’t have let that happen.

The Problem With Non-Exhaustive Matching

Most languages treat pattern matching (or switch/case) as a convenience. You list the cases you care about, slap a default at the bottom, and move on. The problem is that code evolves. New variants get added, old assumptions break, and that default case quietly covers up bugs.

I once worked on a service that retried failed HTTP requests in a tight loop with no backoff and no jitter. When our upstream had a brief outage, every instance of our service fired retries simultaneously, on the same cadence, forever. The upstream came back online, got immediately hammered by a synchronized retry storm from fifty instances, went down again, and the cycle repeated for forty minutes. The “retry” logic had turned a five-minute outage into a cascading failure.

When I joined a team building a multi-region traffic routing system, the first thing I had to understand was why the routing decisions were not always the geographically shortest path. The system was using Dijkstra’s algorithm, but the edge weights were not just latency — they incorporated bandwidth cost, current utilization, failure rates, and SLA constraints. Dijkstra did not care what the weights meant. It just found the minimum cost path. That is its power.

I learned this the hard way. I was building a parsing library and used anyhow::Error as my error type in all public functions. A user opened an issue: “I can’t match on your errors to handle different parse failures differently.” They were right. I’d designed a library with application-level error handling, and it was a terrible experience for consumers. Took me a weekend to refactor everything to typed errors.

Libraries and applications have fundamentally different error handling requirements. Mix them up and you’ll either frustrate your users or drown in unnecessary boilerplate.