I Spent 18 Months Using Rust And Regret It

Rust’s promise—speed without garbage collection—collides hard with the realities of building complex, async-heavy systems. After 18 months rebuilding an algorithmic trading platform in Rust, the narrator lands on a blunt verdict: the language is “great” in narrow areas, but the overall experience becomes so verbose and unintuitive—especially once async, lifetimes, and generics stack together—that development turns into a long cycle of refactoring and frustration.

The performance pitch for Rust starts with a familiar hierarchy: languages that manage memory at runtime (reference counting, shared ownership patterns, garbage collection) tend to lose ground at the top end. Rust is often marketed as a fastest-and-safest option, but the trade-off shows up in practice. The narrator points out that Rust’s “safety” isn’t free: to keep things correct, the language pushes developers into patterns like Arc/Mutex and cloning, and once async enters the picture, the code can become extremely hard to reason about. The most painful moments aren’t basic Rust—they’re the “Ayn land” parts where lifetimes and trait bounds interact with futures across boundaries.

That complexity shows up in concrete coding pain: writing helper abstractions for retry logic over async operations can fail to compile, forcing the developer to abandon helper functions entirely. Even when the core logic is straightforward—start a session, await operations, open a transaction, handle errors with match, and cap retries—the surrounding type machinery can become the bottleneck. The narrator describes a “non-differentiable” learning curve: borrow checking is steep, lifetimes add another steep wall, and async makes everything “go off the table.” The result is a “pit of success” that feels shallow: Rust makes it easy to do the wrong thing quickly (for example, by leaning on the question-mark operator to propagate errors without enough context), so developers may end up debugging behavior they didn’t fully understand.

Error handling becomes a second flashpoint. Rust’s ergonomics—especially the convenience of propagating errors—can hide where failures originate, leading to “oopsy dazing” and vague blame. The narrator contrasts this with Go’s more explicit error handling, which forces context wrapping and makes it clearer where things go wrong. Rust can still be strong here—if developers avoid unsafe unwraps and use better error construction—but the learning curve means many people don’t reach that level quickly.

Despite the regret, the narrator isn’t anti-Rust across the board. Command-line work, file transforms, and certain structured patterns read well. Multi-threading is also described as enjoyable when using Arc/Mutex. Still, for maximum performance in async systems, the narrator concludes Rust is less practical than alternatives like Go or Zig, and the Rust community’s culture can feel overly cult-like or hostile when flaws are raised. The final takeaway is less about Rust being “bad” and more about fit: Rust demands deep mastery before it pays off, and skipping that preparation can turn a promising tool into a long, expensive refactoring loop—one that matters when milliseconds count in trading systems.