My negative views on Rust (2023)
Critiques of Rust’s “negative views” piece center on whether the language’s ownership model, borrow checker, and focus on memory layout impose unnecessary complexity for most real‑world applications, especially when compared to garbage‑collected languages. Many commenters acknowledge real pain points around async, expressing trees/graphs, and pervasive `unsafe` in libraries, but argue that Rust’s safety guarantees, performance, and tooling still make it a strong successor to C/C++ in systems domains and some high‑performance apps. The exchange also highlights a broader tension between using systems languages for everything to fight software bloat versus favoring productivity and simpler abstractions for typical web and business software.
Rust’s Scope: Systems vs General-Purpose Use
- Debate over whether Rust should stay a “systems language” or is appropriate for web apps, CLIs, and higher‑level code.
- Some argue using a systems language broadly helps fight software bloat; others say for many app domains a GC’d language is more pragmatic.
- Several report good experiences building non‑systems tools (CLIs, web backends, game engines) and see Rust as viable general‑purpose.
Memory Model, Borrow Checker, and Data Structures
- Strong split: some see thinking about ownership, borrowing, and layout as essential discipline; others see it as “playing chess with the compiler” for little benefit in many apps.
- Tree/graph structures, especially with parent pointers and mutability, are widely acknowledged as awkward. Workarounds include
Rc/Arc+RefCell/Weak, indices into arenas/slot maps, or resorting tounsafe. - Critics say this friction pushes people toward verbose, unidiomatic patterns; defenders argue it forces clearer architectures and catches real bugs.
Performance vs Simplicity / GC Languages
- Many examples of large speedups moving from Python (and sometimes JavaScript) to Rust even with straightforward ports.
- Counterpoint: similar gains would often come from any compiled language, without Rust’s ownership complexity; in many domains, GC and higher‑level ergonomics win.
Unsafe Code and Safety Guarantees
- Tension between Rust’s “memory safe” branding and widespread
unsafein core data structures, FFI, SIMD, and some crates. - Some users write large Rust codebases with zero
unsafe, relying on safe abstractions; others say implementing efficient custom structures or low‑level work inevitably needsunsafe. - Concern that unsafe buried in dependencies is hard to audit; proposed norms include documenting invariants and tools to surface unsafe usage.
Async Rust and Tokio
- Broad agreement that async is one of Rust’s rough edges: complex, “coloring” everything
async, and tightly coupled to executors. - Some say it’s “fine in practice,” especially if you avoid
tokio::spawnand think in terms of structured concurrency; others still find it a major ergonomic wart.
Panics, Error Handling, and Fail-Fast
- Panics seen by some as overused and turning recoverable issues into crashes; others argue fail‑fast with clear stack traces is better than limping along as in C/C++.
Language Complexity and Evolution
- Disagreement on whether Rust is approaching C++/Haskell complexity. Many argue it’s far simpler on the “sharp edges” and has been relatively stable for years.
- Some worry about growing unstable feature sets, but others note most are lifting limitations rather than adding whole new paradigms.
Community and Meta-Discussion
- Mixed views on the “friendly” Rust community; some see genuine helpfulness, others see dogmatism and hostility to criticism.
- Several note a pattern of highly upvoted negative Rust takes, and liken the pro/anti Rust dynamic to other tech tribalism.