Rust Learning Guide - Anti-Patterns

Wed, 11 Mar 2026 00:00:00 +0000

Overview

The antipatterns.rs module Source Code File demonstrates 15 common Rust mistakes and their correct solutions. I put this together because I noticed the same patterns coming up, especially from developers (myself included) fighting the borrow checker instead of working with it.

Anti-Patterns Covered

1. Unnecessary .clone() Everywhere

❌ Cloning to avoid borrow checker
✅ Use references (&T) instead

2. Using .unwrap() in Production

❌ Crashes program on error
✅ Return Result<T, E> and handle gracefully

3. Returning References to Local Variables

❌ Dangling references (won’t compile)
✅ Return owned data or use ‘static lifetime

4. Using String When &str Would Work

❌ Forces caller to own String
✅ Accept &str - works with both

5. Ignoring Compiler Warnings

❌ Unused mut, unused variables
✅ Listen to the compiler

6. Using Indices Instead of Iterators

❌ C-style loops can panic
✅ Use iterators - safer and clearer

7. Manually Implementing What Traits Provide

❌ Manual equality checks
✅ #[derive(PartialEq, Debug, Clone)]

8. Using Vec When Array Would Work

❌ Heap allocation for fixed-size data
✅ Use arrays [T; N] for stack allocation

9. Nested match/if let Instead of Combinators

❌ Deeply nested matching
✅ Use .map(), .filter(), .and_then()

10. Using Mutex When Not Needed

❌ Mutex in single-threaded code
✅ Just use regular variables

11. Collecting Iterator Just to Iterate Again

❌ Unnecessary intermediate collection
✅ Chain iterators directly

12. Using Deref Coercion as Inheritance

❌ Simulating inheritance with Deref
✅ Use composition explicitly

13. Panicking in Library Code

❌ panic!() crashes caller’s program
✅ Return Result and let caller decide

14. Using format! When to_string() Works

❌ Overkill for simple conversions
✅ Use .to_string() for clarity

15. Implementing Default Manually

❌ Manual new() constructor
✅ Implement Default trait

Key Principle

Work WITH Rust’s ownership system, not against it.

The Anti-Patterns That Kill Teams

Mon, 23 Feb 2026 00:00:00 +0000

Most team dysfunction isn’t unique. It follows recognisable patterns that repeat across organisations, industries, and decades. The good news is that if you can name the pattern, you’re halfway to fixing it. The bad news is that most leaders don’t recognise the patterns until the damage is well advanced.

Osmani catalogues these anti-patterns extensively, and I’ve encountered most of them across my career. Here are the ones that I’ve seen do the most damage, organised by where they originate.

Anti-Patterns on guy@secdev.uk