TypeScript 7.0 RC is here: Compiler fully switched to Go, 10× faster

Yesterday (June 18), Microsoft dropped the RC version of TypeScript 7.0. This update has no flashy new syntax or type operators; the main course is just one dish — the compiler’s underlying implementation has been switched from TypeScript’s self-hosting to a Go rewrite, bringing about a 10x average improvement in compile and type-check speed and roughly halving memory usage.

This is the most radical refactor TypeScript has undergone in the 14 years since its release in 2012. It’s rare in the compiler world to swap out the very language you’re built on while keeping semantics identical — and even rarer to succeed.

Not an Optimization, but a Rewrite

Let’s get the background straight. As early as March 2025, the TypeScript team hinted at this project, codenamed Corsa, led personally by Anders Hejlsberg — no introduction needed: Turbo Pascal, Delphi, C#, TypeScript all bear his imprint. His choice of Go over Rust, C++, or C# sparked quite a debate at the time, with Rust circles expressing notable disapproval.

The team’s reasoning was pragmatic: Go’s semantics are very close to the existing TypeScript code, making line-by-line translation cheapest; garbage collection is hassle-free; concurrency primitives have native support; cross-compilation is easy. They aimed to migrate hundreds of thousands of lines of TS compiler code in the shortest possible time while keeping the test suite fully green — in this scenario, Rust’s ownership model was more of a burden.

This 7.0 RC is the fulfillment of that plan. The official statement is explicit: the port was line-by-line translation — no opportunistic architecture changes, no algorithmic optimizations, even variable names stayed as close as possible to the original. The big payoff is semantic stability: a decade’s worth of regression tests remained untouched and all passed, meaning that upgrading to 7.0 should theoretically cause zero behavioral changes. Such engineering discipline is rare even in large enterprises.

Honest Performance Numbers

This time Microsoft didn’t play word games — the performance data comes from real-world projects:

| Project | Code Size | 6.0 Time | 7.0 Time | Speedup | |---------|-----------|----------|----------|---------| | VS Code | 1.5M LOC | 77.8s | 7.5s | 10.4x | | Sentry | - | 133s | 16s | 8.2x | | TypeORM | 270k LOC | 17.5s | 1.3s | 13.5x | | Playwright | 356k LOC | 11.1s | 1.1s | 10.1x | | rxjs | 2.1k LOC | 1.1s | 0.1s | 11x |

A few points worth noting: First, these aren’t hello-world toy cases — VS Code itself is a 1.5M LOC behemoth; second, TypeORM’s 13.5x boost comes from heavy use of complex generic inference, which the old JS implementation choked on in interpreted execution; third, even small projects (rxjs, 2.1k LOC) saw 11x speedups, proving the acceleration isn’t just for large codebases.

The official breakdown: around 50% of the speedup comes from native code (Go compiled to machine code vs V8 interpreted/JIT), and the other 50% from shared-memory parallelism. This split matters — it shows “just changing languages” gets you half, the rest requires a true execution model overhaul.

Concurrency: The Half JS Couldn’t Reach

Let’s unpack that. Why couldn’t the TypeScript compiler go multithreaded before? Because it ran on Node.js, whose worker_threads each have their own heap; sharing data means serialization, which for type-checking — “traversing a giant type graph repeatedly” — costs more than single-threading. For six years, TypeScript was single-core only; even an i9 with 16 cores sat idle.

Go is different. Goroutines share memory, with scheduling managed by the runtime. During type checks, you can parallelize checks across different modules and files, with all workers reading the same AST and symbol table — no copies. That’s why large projects (like VS Code and Sentry) can consistently get 10x gains.

In other words, this rewrite really unlocked “TypeScript can use multiple cores”. The performance boost is the result, not the goal. When CPUs go from 8 to 32 cores, it can theoretically keep scaling.

LSP Redone, Editor Experience Changed

Beyond tsc, the accompanying language server has also been rebuilt. The new LSP supports multi-threaded request handling, meaning autocomplete, go-to-definition, hover info can all happen concurrently, without the cursor freezing while a full type-check runs in the background.

VS Code users can try it now by installing the TypeScript Native Preview extension. It already supports:

• Auto-import
• Hover tooltips
• Inlay hints
• Code lens
• Rename, find references, and other standard features

Microsoft also shared an interesting stat: under fuzz testing, language server command failure rates dropped to 1/20 of version 6.0’s. So the Go rewrite is not just faster — it’s also tangibly more stable. Go’s strong typing and compile-time checks hold up better than TypeScript itself in such massive codebases.

Fully Compatible with 6.0, but 6.x Will Continue Maintenance

On upgrades, Microsoft is taking a measured approach.

7.0 is semantically identical to 6.0, so in theory you can just change the tsconfig reference. But they’ve stated clearly that the 6.x series will continue to be maintained — because some projects depend on the compiler’s internal APIs, like ts-loader, babel-plugin, and ESLint’s typescript-eslint. These tools call TS’s JS API directly, and it’s impossible for the Go rewrite to perfectly match those APIs.

So for a while we’ll see this coexistence:

• TypeScript 6.x (JS version): Still maintained, covering toolchains that heavily rely on compiler APIs
• TypeScript 7.x (Go native version): Mainline focus, performance-first, general business projects prioritize upgrading

For developers, the bottom line is: if your project is just business code built with webpack/vite, you can upgrade to 7.0 immediately, and your CI time might drop from minutes to seconds. But if you’ve written custom TS transformers or use AST manipulation tools like ts-morph, you’ll need to wait for the ecosystem to catch up.

Some Takeaways Worth Mentioning

From a broader perspective, a few points stand out.

First, the “native-ification” of the frontend toolchain has been pushed further. esbuild (Go), SWC (Rust), Turbopack (Rust), Biome (Rust), Oxc (Rust)… In the past three years almost the entire frontend toolchain has been rewritten in native languages — the last big one left was the TypeScript compiler itself. Now that’s gone too, meaning the era of running the toolchain on Node.js is accelerating toward its end. New projects will increasingly launch with a toolchain not written in JS.

Second, Anders Hejlsberg’s choice of Go over Rust is worth revisiting. That decision took flak, but in hindsight, shipping an RC in just over a year while preserving semantics shows Go’s productivity in “translation-style rewrites” is unmatched by Rust. Rust shines for greenfield projects; Go excels at massive legacy migrations — this case is textbook.

Third, TypeScript has finally cracked the “slows down with project size” curse. Many huge codebases (Slack, Airbnb, Stripe have all complained publicly) suffered type checks taking 10–20 minutes in CI, ruining dev experience. Now the 10x boost brute-forces that away, widening TS’s competitiveness gap with lighter solutions like JSDoc + JS.

Fourth, especially relevant for Chinese devs: Go produces a single binary, which is much cleaner to distribute than npm install-ing a pile of dependencies. Pull a single tsc binary in CI and you’re good to go — great for self-hosted CI, monorepos, Docker image sizes.

How to Try It

If you want to try it now, two ways:

# 1. Install the TypeScript Native Preview extension (VS Code)
# Search "TypeScript Native Preview" in the Extensions Marketplace

# 2. Run the CLI version directly
npm install -D @typescript/native-preview
npx tsgo --version
npx tsgo -p tsconfig.json

Note the command is tsgo, not tsc, to avoid conflicts with your current install. Config files like tsconfig.json don’t need changes.

Microsoft’s timeline: final release expected in the second half of 2026, with a few iterations after the RC. Historically, TS RC stages last 2–3 months, with GA around September–October.

This is TypeScript’s biggest change in 14 years, and the heaviest stone yet to fall in the frontend toolchain native-ification movement. The next thing to watch might be when Node.js bakes TypeScript support into the runtime — Deno and Bun are ahead here; Node 24 just added type stripping, but full type checks still need an external tool.

By the time 7.0 GA lands, the playing field may get reshuffled again.

References

• ITHome: Biggest Change in 14 Years — Microsoft TypeScript 7.0 RC Released, About 10x Performance Boost — Original Chinese report on the RC release, with full performance data
• GitHub: microsoft/typescript-go — Official repo for the Go rewrite of TypeScript, source available
• Zhihu: TypeScript Compiler Go Rewrite Boosted 10x — Deep Dive into Engineering — Engineering details focusing on the concurrency model
• Reddit r/nextjs: TypeScript 7.0 Beta Tested — 10x Boost on Large Codebases — Community dev feedback from real-world tests