Why I Don't Like Rust

Tech/Product/Language Concepts Mentioned (and Why the Speaker Dislikes Rust)

Safety & borrow checker (liked)

• Rust is described as safer than C/C++ because it forces checking errors.
• The speaker says they’re “completely fine” with the borrow checker and hasn’t personally had issues with it.

Compiler difficulty (acknowledged)

• The speaker praises (from a “hardness” perspective) how difficult it is to build Rust’s compiler, claiming it must track:
  • variable declarations
  • creation/destruction lifetimes
  • reference rules (when references are created/deleted)

Rust forces a programming style (main complaint)

The speaker argues Rust pushes programmers toward patterns they dislike:

• Iterators over index-based loops
• Explicit code vs “hidden magic”
  • Rust compiler-generated code, macros, etc.
• Preference for simple code over heavy abstraction
• Dislike of type inference
  • they prefer explicit type annotations
• Preference for procedural programming
  • they claim Rust leans more toward functional-style chaining/combinators
• They also claim Rust’s comment sections/community will respond with: “you’re writing Rust wrong.”

“Hidden magic”: traits/macros/derive, tagged unions, and chaining

The speaker argues Rust’s core abstractions rely on:

• macros (notably derive macros)
• traits (compared to interfaces in other languages)
• tagged unions implemented via Rust’s enum system
• heavy function-call chaining, common in iterator pipelines

They cite examples where functionality like printing/comparing seems to require extra compiler-generated derivations.

---

Example Tutorial/Code Critique: Simulating HTTP Result Handling

To argue Rust’s error handling feels overcomplicated, the speaker uses an example:

• “Open a URL / get page or HTTP error.”

Key claims:

• Rust’s Result is described as effectively a tagged union.
• They complain that to print or compare these values, Rust requires derive (e.g., Debug), suggesting basic behavior should be built-in.
• They argue Rust’s types become “tagged union inside tagged union” for Result-style error handling, creating more mental overhead.

Comparison to Zig

They claim the same idea in Zig is simpler:

• easier printing/comparison without Rust-like derivation requirements
• more straightforward control flow with less reliance on match and derived traits

---

Example Tutorial/Code Critique: Directory Traversal Using Iterator Pipelines

The speaker attempts to write code that recursively walks a directory:

• filters entries
• processes .cpp files

They say Rust makes this difficult because it uses iterator adapters, such as:

• converting directory walking into iterators (into_iter)
• filter_map
• nested filter/map stages
• chained combinators (hard to reason about)

Additional complaints:

• Type names are hard or impossible to write directly because types are generated via compile-time expansion and iterator adapter composition.
• They mention errors when trying to explicitly name intermediate iterator/filter types (e.g., “Cannot find type … in this scope”).

Debugging difficulty claim

• When hovering in an editor, types collapse into generic placeholders.
• They say debugging becomes: “Good luck.”

Contrast to their preferred style

They show a more explicit approach that:

• recursively processes entries
• specifies concrete types

They say this is more understandable to them—even though they claim Rust “fights” that style.

---

Performance/Engine Anecdotes: Stack Overflow & Compilation/Inlining Oddities

Stack overflow from large constants (debug mode)

In a chess/move-generation context, the speaker uses very large compile-time constants (bishop/rook move tables).

Claims:

• Rust debug builds cause a stack overflow
• Rust release works after optimization
• Zig works in both debug and release

They argue this “shouldn’t happen”:

• constants “should be global”
• it shouldn’t fail in debug mode

Compiler optimization/inlining disagreement (methods vs procedural)

In a chess engine optimization, they report:

• moving logic into struct methods (instead of procedural functions / globals) made performance about 40% faster
• they claim the change is mostly structural (not algorithmic)
• because it’s LLVM-based, they expect similar outcomes across languages—so they view it as an unexplained Rust compiler/optimization inconsistency

---

Overall Conclusion (Review Style)

The speaker concludes Rust is not enjoyable for them because it’s:

• overly complex/abstract
• forces disliked idioms (iterators, chaining, inference, macros/traits)
• sometimes behaves unexpectedly (stack overflow with constants in debug; performance differences tied to code organization)

They explicitly say Rust is not “bad”—it’s just not for them.

---

Main speakers/sources

• Primary speaker: the YouTube creator (unnamed in the subtitles), delivering an opinionated review of Rust (“Why I Don’t Like Rust”).