Several core problems with Rust

Meta: Hype, Hate, and Rust Culture

• Several comments frame this as another swing in the tech hype/hate cycle (Rust → now Zig, etc.).
• Some say “Rust haters” have become more annoying than early evangelists; others insist evangelism is still overbearing and anti-Rust posts are a backlash.
• A few argue the post is more “ragebait” than analysis, similar to generic language-war content.

Compilation Speed

• Many acknowledge Rust’s compile times as a real pain point, especially on large projects or modest hardware; some report needing >32 GB RAM or new machines.
• Others counter that Rust has improved, can be faster than C++ in practice, and that careful crate factoring, incremental builds, and build refactoring can yield large speedups.
• There’s debate over what is “inherent” (monomorphization, LLVM backend) vs fixable (compilation model, tooling, parallelism).

Complexity, Ergonomics, and “Rusty” Design

• Some agree Rust is complex, especially around ownership, borrowing, lifetimes, and async; early experience is described as “incredibly painful”.
• Others argue the complexity mostly forces you to understand data and concurrency upfront, catching bugs earlier; pain shifts from runtime to compile time.
• Constructs like Arc<Mutex<...>> are cited as ugly and verbose; defenders say they make problematic patterns explicit and often push you toward better designs (channels, actors, persistent data structures).

Unsafe Code and Data Structures

• One detailed account describes implementing a B-tree with unsafe pointers, then rewriting it using Vec indices: code became simpler, safe, and ~10% faster.
• Several say unsafe Rust is harder to get right than C due to strict aliasing and pointer syntax; Miri catches subtle UB that would silently slip through in C/C++.
• There’s a long subthread clarifying that unsafe does not magically “contain” bugs to a block; invariants must be enforced at module boundaries, and unsafe APIs must be carefully designed.

Memory Safety vs Reliability (the Cloudflare unwrap)

• The article’s claim that Rust “crashes all the time” and trades reliability for memory safety is heavily criticized.
• Many argue unwrap() is equivalent to an assert or sys.exit: a deliberate choice to treat a condition as unrecoverable; the Cloudflare outage is framed as a design/operational issue, not a language flaw.
• Several stress that a clean panic + restart is often preferable to silent corruption or OOM; Rust makes such failures deterministic and searchable.
• Some acknowledge that Rust (and examples) make unwrap() too easy and suggest cultural or tooling norms (linting against it, preferring ? and proper error handling).

Shared Mutable State and Concurrency

• The post’s claim that Rust becomes “meaningless” for heavy mutable shared state (GUIs, DBs, services) draws pushback.
• Critics note that any correct handling of shared mutable state is hard and often slower, regardless of language; Rust just forces explicit synchronization.
• Others agree that idiomatic Rust discourages shared mutability and can make certain patterns (cyclic graphs, heavily stateful APIs) awkward, pushing toward message passing or higher-level abstractions.

Language Choice and Alternatives

• Multiple commenters emphasize Rust is excellent for some domains (systems, infra, security-critical services) but not a universal best choice.
• Alternatives mentioned for different tradeoffs: Go, C#, Swift, Python, Zig, Odin, Ada, D, OCaml, BEAM languages, and GC’d environments for richer shared-state or rapid GUI work.
• Several conclude that the article over-generalizes from one developer’s frustrations; Rust has real downsides, but also large, demonstrated benefits in practice.