Rewriting Rust

Rust’s pace and overall trajectory

  • Some see language progress as having “slowed to crickets,” with long‑standing features (coroutines, TAIT, specialization, effects) still incomplete or unstable.
  • Others argue this slowdown is healthy maturity: Rust is widely usable, stability matters more than rapid change, and deep work (e.g., new trait solver) soaks up bandwidth.
  • Concern exists about Rust Foundation / leadership “drama,” but many commenters still expect Rust to be around long‑term and see growing industrial use.

Async, Pin, and language complexity

  • Async/await is viewed by some as Rust’s biggest success (high‑performance servers, embedded async like Embassy).
  • Others find async ergonomics poor: Pin and manual futures are complex, streams are hard, and there’s a “two‑tier” ecosystem (users vs async-internals experts).
  • There’s tension between wanting more powerful coroutines and fear of unsoundness and added complexity.

Borrow checker, self‑referential types, and ergonomics

  • Desire for first‑class self‑referential structs and partial borrows without Pin; suggestion that the borrow checker could learn more about struct fields, as it already does for locals.
  • Small ergonomic holes frustrate people: inability to easily combine if let with &&, difficulty storing impl Trait in structs, verbose pointer deref syntax.
  • Some feel Rust’s syntax and type signatures have become more unreadable over time; others note newer features (like impl Trait in arguments) can also simplify code.

Compile‑time features, macros, and effects

  • Interest in more powerful compile‑time programming (“comptime”), effect systems, and richer function traits (e.g., tracking panics or IO), but recognition this is technically hard and risks undecidability.
  • Macro system and proc‑macros are seen as powerful but uneven; there’s appetite for better tooling and sandboxing of proc‑macros/build scripts.

Dependencies, capabilities, and supply‑chain risk

  • Strong concern about “dependency jungles” (example: cargo-watch vendoring ~millions of LOC) and difficulty auditing long transitive chains.
  • Debate over whether this is cultural (Rust vs C/C++/Go attitudes) or structural (Cargo / crates.io design, small crates).
  • Proposal: per‑crate capabilities (e.g., restrict filesystem access, unsafe, syscalls) checked at compile time to reduce blast radius of supply‑chain attacks.
  • Critics say full sandboxing can’t be done purely at language level and needs verifiers or WASM‑style isolation; proponents argue even partial, opt‑in capability systems would be a major improvement.

Governance, RFCs, and unstable backlog

  • Many note the “graveyard” of unstable features and long‑running RFCs as evidence of decision bottlenecks and bikeshedding.
  • Others stress that some unstable features are experiments that should die, not ship, and that editions and caution are preferable to a Python‑2/3‑style split.