Rust Is Eating JavaScript (2023)

Original Article ↗ Hacker News Discussion ↗

Article scope, title, and dating

  • Many note the piece is really about Rust in the JavaScript toolchain (bundlers, linters, formatters), not Rust replacing JS in app code. Suggested title: “Rust is Eating JavaScript Tooling.”
  • Some think the article is misleading by omitting its original 2021 date and talking about now-archived projects like Rome as if current; others point out there is a short 2023 update.
  • A few tools referenced as “dead” now have successors (e.g., Biome) and new Rust companies, so the ecosystem is in flux.

Rust’s ecosystem and funding

  • Concern that Rust tooling sees many ambitious projects abandoned due to lack of deep, sustained funding compared to C/C++ (hardware vendors) or Java/JS (big tech frameworks).
  • Others counter that major companies have funded Rust and interop work, but agree we haven’t yet seen Rust equivalents of React‑scale ecosystem projects.

WebAssembly’s current limitations

  • Multiple comments stress that WASM is not yet a first‑class browser language because:
    • It cannot directly access the DOM; everything must go through JS glue, with significant marshalling overhead.
    • The standard ABI is low‑level (integers, pointers into linear memory only), making rich bindings hard.
  • Work on the WebAssembly Component Model and WIT is cited as a future path to safer, higher‑level host–WASM interaction, but it’s still “in the works.”

Memory management, GC, and performance

  • Long subthread on “garbage” in Rust vs GC’d languages:
    • One side: Rust’s RAII and deterministic frees mean no runtime GC; heap allocations aren’t “garbage” in the technical sense.
    • Others argue “automatic memory management” (including RAII and reference counting) shares many downsides with GC, and that in some workloads GC can be competitive or faster.
  • For short‑lived tools like Babel/Prettier, several argue GC vs non‑GC is mostly irrelevant; speed and safety (null‑pointer, type) matter more.

Rust vs Go vs JavaScript/Python for tooling and CLIs

  • Broad agreement that compiled languages dramatically outperform JS tooling; esbuild (Go) is often cited as an example.
  • Disagreement on Rust vs Go:
    • Some prefer Rust for safety and maximum performance; others find Rust’s borrow checker overkill for CLIs and favor Go’s simplicity and faster development.
    • A view emerges that Rust shines where low overhead, startup time, and static binaries are crucial (developer tools, search utilities, etc.).
  • Java is debated:
    • Pro‑Java side highlights decades‑old strengths: shared types across client/server, hot reload, rich tooling and libraries.
    • Critics cite verbosity, startup/memory overhead, ecosystem “enterprise” complexity, and build tools (Maven/Gradle) as reasons many moved to Rails, Node, Go, .NET, etc.

Rust hype, fashion, and backlash

  • One camp says Rust is being adopted because it’s appropriate for systems‑style tasks and WASM, not just “cool kids” fashion.
  • Another compares Rust hype to past C++/Rails/Scala/Go cycles and complains about “X but in Rust” projects where GC languages would suffice.
  • A counter‑camp pushes back on dismissive attitudes toward experimentation, seeing these projects as healthy exploration even when not strictly necessary.

Impact beyond JavaScript: Python, WASM, and “fast cores”

  • Discussion notes Rust “eating” Python too via tooling like Ruff and uv; concern that strong type tools (mypy/pyright, future alternatives) are under‑adopted in industry.
  • Several foresee a future where JS/TS (like Python) remains the ergonomic “glue,” while performance‑critical library internals are written in Rust and compiled to WASM (e.g., DOM diffing engines, crypto libs).

Type sharing, API schemas, and DX

  • Some praise full‑stack TypeScript: shared types between React frontends and TS backends make API changes safer and faster.
  • Others argue you can get similar DX cross‑language via OpenAPI/Swagger or GraphQL schemas, with generators producing typed TS clients from Rust, C#, or other backends.
  • Multiple real‑world setups are described that generate TS clients from C# or Rust servers using OpenAPI and various tooling.

JavaScript on the backend and job market perceptions

  • Strong anti‑Node/JS‑backend sentiment appears: critics call JS poorly designed and ill‑suited for mission‑critical backends, preferring Go, Rust, C#, Python, etc.
  • Others defend TS backends as “more than fine,” noting expressive type systems and strong ecosystems.
  • Perceptions of job trends diverge by region: some report fewer Node backend roles and more Go/Rust/C#, others see Node growing alongside Java.

Meta: thread quality and language tribalism

  • A few participants lament the thread as dominated by subjective language‑bashing and recurring “X vs Y” flamewars, with little new evidence, but acknowledge that these debates resurface regularly whenever Rust and JS intersect.