Rust--: Rust without the borrow checker

Project Nature & Motivation

• Repository removes Rust’s borrow checker errors by suppressing them in a custom compiler fork.
• Started as satire (continuation of a prior “corroded” meme crate) but evolved into genuine curiosity: “how hard is it to remove the checker?” and “could this help for debugging/prototyping?”
• Author reports it was surprisingly easy once they found where errors are emitted.

Borrow Checker Semantics & Safety

• Multiple commenters stress: the borrow checker is central to Rust’s safety model, not a minor feature.
• Removing it doesn’t just make code “less safe”; it makes code that violates Rust’s aliasing and ownership rules invoke undefined behavior, similar to C/C++.
• Some clarifications:
  • The borrow checker doesn’t control when objects are dropped; it validates references and lifetimes.
  • Codegen assumes the rules hold (e.g., &mut implies no aliasing, enabling optimizations like noalias), so breaking them is UB.
  • unsafe blocks don’t disable the borrow checker; they only allow certain operations (raw pointers, calling unsafe fns). References are still checked.

Use Cases: Prototyping, Debugging, Exploration

• A minority finds the idea appealing for:
  • Fast experimentation where refactors to satisfy the checker feel like “upfront tax.”
  • Debug-style workflows (lots of temporary prints) where moves, Debug traits, or borrows get in the way.
• Others argue:
  • You’ll just accumulate UB-riddled code that must be rewritten.
  • In Rust, large refactors are easier once the compiler is satisfied, and the borrow checker improves long‑term velocity.
  • Rc/Arc, RefCell, and local unsafe are better knobs than a global “off switch.”

Language Philosophy & Alternatives

• Strong pushback: globally disabling borrow checking is seen as against Rust’s ethos (“care deeply about memory safety, use unsafe sparingly and encapsulated”).
• Some wish for:
  • The opposite: borrow checker as a standalone tool for alternative compilers or other languages.
  • More nuanced or relaxed modes (warnings instead of errors, or specific relaxations like multiple mutable borrows), though many note this is hard or dangerous.
• Broader debate surfaces:
  • Rust as “straightjacket vs. railroad track”: safety and guarantees vs. creativity and ease.
  • Comparisons with C/C++ and GC languages (Go, Java, C#) on correctness, ergonomics, performance, and domain suitability.

Ergonomics, Complexity, and Learning Curve

• Several discuss Rust’s perceived complexity:
  • Lifetimes and borrow rules are the main pain points; Rust’s other features (expressions, pattern matching, traits, ?) are praised.
  • Some find C/C++ “easier to start” but acknowledge they silently accept dangerous code that later explodes.
• Others counter that after initial “fighting the borrow checker,” they rarely struggle with it and it improves code quality across languages.