Anti-Patterns on

Lesson 10: Using unsafe to Escape the Borrow Checker — The wrong reason

Thu, 24 Apr 2025 09:30:00 +0000

I found this in a production codebase:

fn get_or_insert(&mut self, key: &str) -> &mut Value {
 if !self.map.contains_key(key) {
 self.map.insert(key.to_string(), Value::default());
 }
 // "The borrow checker is being stupid, we know the key exists"
 unsafe { &mut *(self.map.get_mut(key).unwrap() as *mut Value) }
}

The comment says it all. The developer hit a borrow checker error — a legitimate one about borrowing self.map mutably twice — and instead of restructuring the code, they cast through a raw pointer to silence the compiler. This is undefined behavior. The compiler is allowed to assume the mutable references don’t alias, and it will optimize based on that assumption. When it does, your program does something you didn’t write.

Lesson 9: Macro Abuse — When a function would do

Mon, 21 Apr 2025 17:08:00 +0000

I spent an entire afternoon debugging a test failure that turned out to be caused by a macro expanding variable names in a way I didn’t expect. The macro was called make_handler! and it generated HTTP handler functions from a declarative DSL that someone on the team had invented. The “DSL” saved maybe ten lines of boilerplate per handler. The macro definition was 200 lines of nested macro_rules! with five recursion levels, three tt munchers, and hygiene workarounds that I’m still not convinced were correct. When a new developer asked how to add a query parameter to a handler, nobody could explain it without first teaching them how the macro worked.

Lesson 8: Premature Optimization — Profile before you optimize

Sat, 19 Apr 2025 13:42:00 +0000

A teammate once spent three days replacing every String in our data model with a custom arena-allocated string type. The rationale: “String allocations are slow, and we’re processing a lot of data.” Sounds reasonable, right? After the rewrite, I ran the benchmarks. The improvement was within noise — less than 1%. The actual bottleneck was network I/O to an external API, which accounted for 94% of the request latency. Those three days of intricate unsafe string manipulation? Completely wasted. And the code was now harder to read, harder to maintain, and had a subtle use-after-free bug that we found six weeks later.

Lesson 7: Arc> as Default — Reach for channels first

Wed, 16 Apr 2025 20:15:00 +0000

There’s a specific moment in every Rust developer’s journey where they discover Arc<Mutex<T>> and start putting everything in it. I’ve been that developer. I had a web service that needed to share a cache between request handlers, and my first instinct was Arc<Mutex<HashMap<String, CachedItem>>>. It worked. Then traffic went up, contention went up, tail latency went up, and I spent a weekend profiling lock contention that shouldn’t have existed in the first place — because most of my “shared mutable state” could have been restructured as message passing.

Lesson 6: Trait Bloat — Interface segregation in Rust

Tue, 15 Apr 2025 09:55:00 +0000

I worked on a project that had a Storage trait with twenty-three methods. Twenty-three. It handled reading, writing, deleting, listing, searching, watching for changes, managing permissions, computing checksums, and streaming large files. Every backend — S3, local filesystem, in-memory for tests — had to implement all twenty-three methods. The in-memory test backend had fourteen methods that just returned unimplemented!(). The local filesystem backend panicked on the permissions methods because POSIX permissions don’t map to the trait’s model. And every time someone added a new method to the trait, every backend had to be updated — even the ones where the new method made no sense.

Lesson 5: Over-Genericizing — Not everything needs

Sun, 13 Apr 2025 11:28:00 +0000

I reviewed a library last year where the author had made literally everything generic. The HTTP client was generic over the transport, the serializer, the deserializer, the error type, the retry policy, the timeout strategy, and the logger. Using it required spelling out a type signature that looked like this:

let client: HttpClient<
 TcpTransport<TlsConfig>,
 JsonSerializer<PrettyPrint>,
 JsonDeserializer<StrictMode>,
 AppError,
 ExponentialBackoff<SystemClock>,
 FixedTimeout,
 SlogLogger<JsonFormat>,
> = HttpClient::new(/* ... */);

The kicker? The library was an internal tool used by exactly one team. There was one transport, one serializer, one error type. Every type parameter had exactly one implementation. The author had written an extensible framework for a problem that didn’t need extending.

Lesson 4: God Structs — When types do too much

Fri, 11 Apr 2025 16:10:00 +0000

I once opened a file called app.rs and found a struct with forty-two fields. Forty-two. It held the database connection, the HTTP client, the cache handle, the logger, the config, the metrics collector, the rate limiter, the auth provider, the feature flags, the email sender, the template engine, and about thirty other things I’ve blocked from memory. Every function in the codebase took &self on this monster. Need to send an email? You need the god struct. Parse a config value? God struct. Log a message? Believe it or not, god struct.

Lesson 3: Stringly Typed APIs — Use enums, not strings

Wed, 09 Apr 2025 08:47:00 +0000

I inherited a Rust codebase once where the entire state machine was driven by string comparisons. The order status could be "pending", "processing", "shipped", "delivered", or "cancelled". Except sometimes it was "Pending" with a capital P. And there was one code path that set it to "canceled" — one L, American spelling. And another that used "CANCELLED". The bug lived in production for weeks because nobody could figure out why some orders were getting stuck in a phantom state that didn’t match any of the if status == "cancelled" checks scattered across thirty files.

Lesson 2: unwrap() in Production — Time bombs waiting to explode

Mon, 07 Apr 2025 14:35:00 +0000

A service I was responsible for went down at 2 AM on a Saturday because of a single .unwrap() call on line 847 of a file nobody had touched in months. The function parsed a config value that was supposed to always be present. Somebody changed the config format in a different repo, the value became optional, and that .unwrap() detonated like a landmine — thread 'main' panicked at 'called Option::unwrap() on a None value'. Down. Dead. Pager screaming.

Lesson 1: .clone() Everywhere — Hiding ownership problems

Sat, 05 Apr 2025 10:22:00 +0000

I was reviewing a pull request last year from a developer who’d been writing Rust for about three months. The code compiled. The tests passed. Everything looked fine — until I ran grep -c '\.clone()' src/ and got back a number that made me physically uncomfortable. Forty-seven clones across six files. The codebase was a data pipeline processing millions of events per hour, and this person had turned every ownership error into a .clone() call until the compiler stopped yelling.