A 10x Faster TypeScript

Original Article ↗ Hacker News Discussion ↗

Language choice: Go vs Rust vs C#

  • Many expected Rust; discussion converges on why Go is a better port target:
    • TS compiler heavily relies on GC and cyclic graphs; porting that to Rust’s ownership model and borrow‑checker would be extremely invasive.
    • Goal is a near line‑for‑line port, not a redesign; idiomatic Go (functions + structs, mutation, GC) is close to existing TS patterns.
    • Rust is seen as “hard” for many engineers; Go’s low cognitive load and strong tooling favor long‑term maintainability.
  • C# is debated heavily:
    • NativeAOT exists and can produce small, fast binaries, but TS team says it’s less “battle‑hardened”, not universal across platforms, and more bytecode‑first than native‑first.
    • TS core is non‑OO, while C# nudges toward classes and OO idioms; Go fits the current style.
    • Some see this as a political blow to .NET; others see it as a pragmatic choice.

Memory model & safety

  • Several subthreads argue whether Go is “memory safe”:
    • Data races on multiword structures (interfaces, maps, slices) can cause corruption and segfaults; Go defines this but doesn’t prevent it.
    • Rust offers stronger guarantees (no data races in safe code), but both still have escape hatches (unsafe in Rust, races in Go).
    • Consensus: Go is “memory safe with unsafe concurrency” and sits far closer to Java than to C/C++.

Port vs rewrite; interop and embedding

  • TS team stresses: this is a port, not a redesign:
    • Keeps semantics and structure aligned so bugfixes can be mirrored between JS and Go for years.
    • Heavy AST/graph processing maps well to Go’s data layout and concurrency.
  • Embedding concerns:
    • Standalone Go binary favors IPC/LSP‑style integration; some tools that currently embed the JS compiler will need new APIs or WASM.
    • IPC (stdio, sockets, shared memory) is seen as workable but more operationally complex than in‑process libraries.

Performance, tooling, and ecosystem impact

  • Benchmarks: ~3.5× from native Go vs JS + several × from parallelism ⇒ ~10× build/typecheck speed; CI and editor responsiveness expected to improve dramatically.
  • Some ask why not optimize JS or do TS→native AOT directly:
    • TS compiler uses patterns that defeat current JS JIT optimizations (polymorphic access, massive object graphs, one‑shot runs).
    • Native plus threads is seen as a more reliable win than contorting JS for JITs.
  • JS tooling trend noted: esbuild, Biome, swc, etc. already moved heavy work to native (Go or Rust); this aligns TS with that direction.

Browser, WASM, and playground

  • Concern: TS Playground / in‑browser tools.
    • Plan is to compile the Go compiler to WASM eventually; performance may still be fine given the raw speedup.
    • For most users, TS compilation happens in Node/CI, not the browser, so native CLI is prioritized.

Compatibility, APIs, and migration

  • JS‑based 6.x line will be maintained in parallel while 7.x (Go) matures.
  • Some breaking changes in 6.0 are planned to align with the new core and to narrow the public API surface.
  • Heavy compiler‑API users (AST transforms, linting, code mods) worry about:
    • Roundtripping large ASTs over IPC being too chatty.
    • Needing new curated APIs or even Go‑side plugins instead of today’s very open JS API.

Meta: title and “faster TypeScript”

  • Multiple commenters find “10x Faster TypeScript” ambiguous or clickbaity:
    • Clarify: runtime JS is not 10× faster; the compiler and language services are.
    • Others argue anyone familiar with TS knows it has no runtime, so “faster TS” naturally means faster tooling.