Why Microsoft Rewrote TypeScript in Go for a 10× Speed Boost

Background

Several months ago Microsoft announced a complete rewrite of TypeScript in Go, claiming up to ten‑fold speed improvements in tests such as VS Code projects. The new repository typescript‑go quickly gathered over 14 000 stars, sparking curiosity about the choice of Go over Rust.

Interview Overview

The interview, hosted by the Michigan TypeScript channel, features Anders Hejlsberg, TypeScript’s co‑founder and chief architect, discussing the motivations, technical trade‑offs, and future implications of the rewrite.

Why Go?

Go was selected because it is a systems‑level language designed for high‑performance workloads, offers automatic garbage collection, and provides a simple concurrency model with goroutines and mutexes. Rust was rejected due to the existing codebase’s reliance on automatic GC and extensive cyclic data structures (AST, symbol tables, type system) that would be difficult to port.

Performance Gains

Early prototypes showed a 3–3.5× speed boost from native execution and another 3–3.5× from concurrent processing, combining to roughly a ten‑fold overall improvement. Memory consumption dropped by about 50 % thanks to tighter data‑layout and inline structs.

Concurrency Model

The new architecture leverages shared‑memory concurrency, allowing parallel parsing of source files. Parsing can be split across CPU cores with minimal code changes—approximately ten lines of Go using goroutines and mutexes. Type checking, however, remains more complex because it requires a whole‑program view; the team partitions the program into four parts, each checked by a separate type‑checker instance.

Compatibility and Migration Strategy

To preserve behavior, the team migrated the existing codebase rather than rewriting from scratch, ensuring the same semantics and error messages. They maintain a versioned API for language services and plan to support LSP, enabling tooling to adopt the new compiler gradually. Compatibility with existing JavaScript‑based tools is addressed by keeping the same type system features (union, intersection types) while acknowledging some differences in advanced type features.

Challenges

Deterministic type ordering in a multithreaded environment required new algorithms.

Designing a modern, versionable API that works across process boundaries without exposing the entire old JavaScript API.

Balancing the need for high performance with the desire to keep the codebase approachable for contributors.

Future Directions

With a faster compiler, the team envisions tighter integration with AI and generative programming, allowing real‑time verification of LLM‑generated code for both syntactic and semantic correctness. They also consider exposing native TypeScript runtimes and expanding language‑neutral bindings.

Community Impact

The migration is expected to benefit tool developers (linters, formatters) by providing a faster backend, though the exact gains depend on each tool’s architecture. The team plans to maintain the legacy JavaScript compiler for several more years to support projects that cannot yet transition.