TypeScript 7 — Microsoft rewrites the compiler in Go, claims 10x speedup

On March 11, 2025, Microsoft published a TypeScript dev blog post announcing that TypeScript 7 — the next major version of tsc — would be a complete rewrite in Go. The compiler that had been written in TypeScript itself (with the meta-fun of being self-hosted) was getting a native-language port. Claimed benchmark: 10x faster compile times on real codebases.

Fireship’s March 12 video — “Microsoft goes nuclear on TypeScript codebase…” — caught the announcement the day after and asked the question every TypeScript developer was asking: why Go, of all languages? Anders Hejlsberg (TypeScript lead, original C# designer) had the answer publicly, and the community spent the next month dissecting it.

What Microsoft actually announced

From the announcement and Fireship’s breakdown:

• TypeScript 7 will be a Go rewrite of the compiler. Not a wrapper, not a transpilation — a full reimplementation.
• Claimed 10x faster builds on real-world codebases. VS Code’s own TypeScript codebase: ~80 seconds in current tsc, ~8 seconds in Go port.
• Coexisting with current TypeScript 5.x line during transition. Existing TypeScript code continues to work identically.
• Same language semantics, type system, behavior. This is a compiler rewrite, not a language redesign.
• Better tooling, parallelism, memory usage as side benefits of the native runtime.
• Open source on GitHub as a separate repo (microsoft/typescript-go).

The pragmatic argument: the existing tsc compiler, written in TypeScript itself, runs on Node.js. Node has GC overhead, JIT warmup, single-threaded execution by default. A native Go compiler can use multiple cores, has predictable memory characteristics, and just runs faster on cold-start builds. For large monorepos where tsc dominates the build time, 10x speedup is real money saved on CI.

Why Go, specifically

This was the entire community’s question. Reasonable alternatives existed: Rust (popular for compilers like rustc, swc, biome), C# (Microsoft’s own language, would unify with .NET), C++ (Microsoft’s traditional systems language).

Anders Hejlsberg’s stated reasons, surfaced in the blog post and follow-up Q&A:

1. Memory model fit. TypeScript’s existing compiler architecture leans heavily on a “cyclical graph of nodes” data structure. Go’s garbage collector and reference semantics map cleanly. Rust’s ownership model would require significant rearchitecting.

2. Cross-platform tooling maturity. Go produces single-binary outputs cross-platform with minimal toolchain overhead. Distribution and CI integration is trivial.

3. Concurrency primitives. Go’s goroutines map well to the parallelization the compiler can do for independent module compilation.

4. Practical engineering velocity. Rust would have been slower to write the initial port. The team prioritized getting to a working compiler, then optimizing, rather than starting with maximum-performance choices.

The Fireship video and the community largely accepted these reasons but with the persistent question: “why not Rust?” echoing through every comment section.

Creator POV vs Reddit dissent

Fireship’s POV is the appropriately bemused industry-observer one. The video acknowledges the genuine performance win, gestures at the technical reasons for Go, and notes the irony of the TypeScript team (Microsoft, the C# lab) choosing Google’s language for a rewrite.

The r/typescript and r/programming dissent through March:

• “Why Go and not Rust?” The dominant question. Multiple long-form responses from people who had read the Microsoft blog carefully explaining the architectural fit. Few converted skeptics — many believed Rust would have been better long-term.
• “This invalidates years of TypeScript-in-TypeScript bootstrapping.” True — the dogfooding argument loses. Counter: dogfooding mattered for language design feedback; the language is now mature, the compiler can be in any language.
• “Will the language semantics drift?” Concern that the Go port might subtly differ from the TS port. Microsoft’s commitment: zero semantic differences, extensive cross-implementation test suites.
• “This affects swc, esbuild, biome, etc.” The broader TypeScript-tooling ecosystem (largely Rust-based with swc and biome, Go-based with esbuild) suddenly has a Microsoft-blessed Go competitor. Implications for the ecosystem unclear; the answer mostly was “the OSS tools will continue to exist and compete on different axes.”

The mature read settling through April 2025: TypeScript 7 in Go is a major engineering improvement, the language-choice debate is mostly aesthetic, and the broader tooling ecosystem will sort itself out over the next 12-18 months.

What this means for working engineers in March 2025

Three practical positions:

1. If you have a large TypeScript monorepo, get on the Go port’s preview as soon as it’s stable. CI time savings will be substantial. Real money.

2. Don’t migrate off swc/esbuild reactively. They’re battle-tested, fast for their use cases (transpilation vs type-checking), and will continue to be valuable. TypeScript 7 doesn’t replace them; it competes with tsc 5.x.

3. Watch the type-checking ecosystem. The Go port might enable type-checking patterns that were prohibitively slow in tsc 5.x (e.g., very large monomorphization, complex inference at scale). Some patterns considered “don’t do this” in 2024 may become viable in 2026.

The bigger story

This is the second major language-tooling rewrite of the 2020s in a native language for performance — first the Rust-based JavaScript ecosystem (swc, biome, rspack), now TypeScript itself in Go. The pattern: JavaScript ecosystem tools written in JavaScript hit performance walls; they get rewritten in native languages; the native versions become the new default.

The next domino: linters and formatters. Prettier and ESLint are still JavaScript-based. Biome (Rust) is gaining ground. Whether the JavaScript-based incumbents survive or get displaced is one of 2025-2026’s open questions.

The honest critique

What this announcement doesn’t change:

• TypeScript the language is unchanged. Same syntax, same type system, same semantics. The rewrite is about how tsc is built, not what TypeScript is.
• TypeScript 5.x will be maintained for a long time. Production users don’t need to migrate quickly. The Go port is opt-in for the foreseeable future.
• It doesn’t solve the broader TypeScript editor-tooling story. VS Code’s TypeScript language server is also Node-based and slow for large codebases. The Go port may or may not benefit the IDE side of things.

For most working engineers reading this in mid-March 2025: the TypeScript Go rewrite is a real performance win that benefits anyone with a large TypeScript codebase. It’s not urgent — TypeScript 5.x works fine, the Go port is in early preview. But for build-time-sensitive projects, this is the most interesting compiler-side development of 2025.