Atharva Pandey Gopherine

The moment I knew our Rust project structure was broken was when a junior engineer asked me where to put a new endpoint. I opened the repo, stared at the src/ directory, and realized I couldn’t confidently answer. We had 40,000 lines of Rust spread across files with names like utils.rs, helpers.rs, types.rs, and the ever-popular misc.rs. Everything compiled. Nothing made sense.

Most Rust tutorials stop at “put your code in main.rs and maybe lib.rs.” That works for a CLI tool or a weekend project. It completely falls apart when you’ve got a team of eight engineers building a platform with multiple services, shared domain logic, and infrastructure that’s evolving every sprint.

Every backend developer eventually writes the same code: a function that takes a database connection, runs a query, maps the rows to a struct, and returns it. Then you write another one. And another. Pretty soon your business logic is tangled up with SQL strings and connection pool handles, and testing anything requires a running database.

The Repository pattern fixes this. It’s old — Martin Fowler wrote about it in 2002 — but the way Rust implements it is genuinely different from what you’d do in Java or C#. Rust’s trait system, combined with generics and lifetimes, gives you a repository abstraction that’s zero-cost in production and trivially mockable in tests.

Here’s a hot take: most “Factory pattern” usage in Java and C# exists purely to work around limitations of constructors. Constructors can’t have descriptive names. They can’t return a different subtype. They can’t fail gracefully. So you wrap them in a static method and call it a Factory.

Rust doesn’t have constructors at all. Every struct is constructed directly, and associated functions already do what Factory Method does in OOP. So do you even need the Factory pattern in Rust?

I remember the moment Decorator clicked for me. I was reading the source for Java’s I/O library — BufferedInputStream wrapping FileInputStream wrapping InputStream. Three layers deep, each adding behavior without subclassing. Elegant. Then I tried to write the same thing in Rust and learned that “wrapping a thing while preserving its interface” is a fundamentally different exercise when you don’t have inheritance.

The good news? Rust’s version is often better than the OOP original, because composition is the default and the compiler enforces the contracts.

Most Go developers write concurrent code for years without thinking about the scheduler. That’s by design — the scheduler is supposed to be invisible. But eventually you’ll hit a situation where goroutines aren’t running when you expect them to, CPU cores are idle while goroutines pile up, or a CPU-bound workload is somehow slower with more goroutines. At that point you need a mental model of what’s actually happening under the hood.

The Command pattern has always struck me as one of those patterns that’s really just “wrap a function call in an object.” In Java, you create a Command interface with an execute() method, make a class for each command, and pass them around. It takes about 40 lines of boilerplate to do what a lambda does in one.

In Rust, closures are the Command pattern. But when you need undo, history, or serialization, you still need the structured version — and Rust’s ownership model makes the undo/redo part surprisingly elegant.

In most languages, a function returns one thing and communicates failure through a side channel — an exception, a null, a magic sentinel value. Go’s approach is different: functions can return multiple values, and the convention is to use that to make failure explicit in the signature itself. Once you’ve used it for a while, hiding failures in side channels starts to feel dishonest.

The Problem

Sentinel values are the old-school way to signal failure from a function. You pick some value that “shouldn’t” appear in normal results and treat it as an error signal:

The Observer pattern is where Rust’s ownership model gets really opinionated. In C# or Java, Observer is simple — maintain a list of listeners, call a method on each when something happens. But “a list of mutable references to objects that can be called at any time” is basically everything Rust’s borrow checker exists to prevent. So how do you do event-driven programming in Rust? You have more options than you’d think, and some of them are better than what OOP languages offer.

Most DP problems have a clean one-dimensional state: position in an array, remaining capacity, current index. State machine DP adds another dimension that isn’t just a number — it’s a mode or status that your system is in. “Am I currently holding a stock? Am I in a cooldown period? Which color did I just paint the last house?”

The stock trading problems are the canonical example. LeetCode has an entire series of them (I, II, III, IV, with Cooldown, with Transaction Fee) that all share the same structure but add constraints one by one. Solving them all with the same mental framework is satisfying once the state machine clicks.

In my first real Go project, I wrote an interface for a payment processor. Two implementations — Stripe and PayPal. Simple polymorphism. When I tried the same thing in Rust, the compiler hit me with a wall of errors about dyn, Box, object safety, and sized types. It took me a full afternoon to understand what was happening. The Strategy pattern — which is trivial in most OOP languages — forced me to actually understand Rust’s type system. And I came out the other side a better programmer for it.