Unexpected productivity boost of Rust

Rust vs Python and dynamic languages

• Strong agreement that Rust’s static, expressive type system boosts reliability and refactoring confidence compared to Python, JavaScript, etc.
• Others push back on blanket claims like “can’t build reliable software in Python”, citing large real-world systems and arguing that reliability is mostly about skill, tests, and discipline.
• Python is praised for REPL-driven rapid prototyping and small scripts, but several comments note that “throwaway” scripts often end up in production and become painful to evolve.
• Debate over Python’s ecosystem: some call it one of the best-documented languages with excellent tooling; others criticize its docs, performance, and historically messy packaging (improved by newer tools).

Type checking and tools (Pyright, mypy, TypeScript)

• Many argue that the big productivity win is “use a type checker”, not “use Rust specifically”; Pyright in particular is seen as a major upgrade over mypy and can catch many bugs.
• Skeptics say Python’s type system plus checkers still don’t approach Rust/C#/Java for “fearless refactoring”, especially given incomplete or incorrect annotations and unsound systems (e.g. TypeScript).
• Very large legacy Python codebases can emit tens of thousands of type errors when first checked, making incremental adoption hard.

Async, mutexes, and Send/Sync in Rust

• Long subthread explains how Rust encodes thread-movability and concurrency safety via Send/Sync marker traits, RAII, and compiler-generated Future state machines.
• Holding a MutexGuard across await makes the future non‑Send, which async runtimes like Tokio reject if they may move tasks across threads. Releasing the lock before await restores Send.
• Disagreement over when to use std::sync::Mutex vs async-aware mutexes (Tokio/Futures); some call sync mutexes in async code an antipattern, others say they’re fine for short critical sections.
• Separate discussion on async cancellation: futures can be dropped at any await, so holding locks or mutating shared state across await can create subtle bugs.

Fearless refactoring and ML-style type systems

• Multiple reports of large Rust refactors (and Haskell/F# experiences) where code compiled after massive changes and tests passed on the first run. This is tied to ADTs/sum types, pattern matching, ownership, and traits.
• Some note that most of these benefits are shared by “Standard ML–influenced” languages (OCaml, F#, Haskell, Scala, Swift), not unique to Rust—Rust’s novelty is combining them with systems-level control and mainstream adoption.
• Others emphasize that Rust’s borrow checker and ownership model add dimensions (lifetimes, aliasing, thread-safety) not present in many statically typed languages.

Zig and other language comparisons

• The Zig error-handling example (comparing against the global error set and silently getting the wrong value) is widely seen as a dangerous footgun; later linked as an acknowledged compiler issue to be turned into an error.
• Some defend Zig’s “auteur” design and willingness to break APIs to improve low-level performance, contrasting it with Rust’s more conservative ecosystem.
• General agreement that all languages have footguns (e.g., mutex misuse in Go/Zig, Rust’s as casts, C’s pointer tricks), but Rust explicitly tries to make many classes of misuse unrepresentable.

JavaScript/TypeScript href bug and API design

• Many commenters argue the window.location.href bug is primarily a DOM/browser API quirk and a straightforward control-flow mistake (missing return/else), not TypeScript’s fault.
• Others note that better API design + stronger type systems could encode “this call never returns” (e.g., TypeScript’s never, Rust’s !) or ownership-like patterns, making such misuse harder.
• Broader point: good language and API design reduce the number of “implicit assumptions” developers must remember about the environment.

Productivity, tooling, and compile times

• Several people report that Rust’s initial friction is offset by large gains as projects grow, especially with multiple contributors and long-lived code.
• Others complain about Rust’s long compile times and say many of the “productivity curve” claims should be tested against other serious statically typed languages (Java, C#, Scala, Go), not only Python/TS/Zig.