Why Not Rust? A Balanced Look at Its Real Trade-offs

This 2020 essay argues that Rust, despite its strengths, isn't always the right tool for the job. Most software doesn't actually need systems-level control or garbage-collector-free performance — managed languages like Kotlin or Go often deliver sufficient speed with far less complexity.

The piece highlights concrete costs: Rust's ownership and borrowing model forces developers to choose between owned values, references, Box, Rc, or Arc even for simple structs, a decision Kotlin sidesteps entirely with a single class declaration. Compile times suffer because Rust deliberately trades build speed for runtime performance, and the lack of a pimpl-like idiom means changing one crate forces recompilation of all its downstream dependents.

Maturity gaps are also flagged: a single production compiler (rustc), an incomplete alternative implementation (mrustc), one production-ready backend (LLVM), and no official language specification. Tooling weaknesses compound this — missing heap profilers, and large-scale automated refactoring that remains out of reach compared to Java. Interop with the C/C++-dominated systems world requires unsafe, not always zero-cost bridges, and Rust's performance can lag C++ in specific cases due to memcpy-based move semantics and ABI inefficiencies.

The overall takeaway is nuanced: Rust occupies an interesting point on the safety/cost curve, but alternatives like modern C++, Ada, formally verified C, or Zig for constrained single-threaded workloads may be a better fit for certain projects.