TypeScript 7 Rewrites the Compiler in Go — The Real Story Behind the 10x

Every developer has watched tsc chew through a build long enough to finish a cup of coffee. On large codebases, type-checking alone can eat several minutes. So the TypeScript team decided to fix it the hard way — not by tuning the compiler, but by rewriting the whole thing. In Go, of all languages.

One caveat before we dig in. This topic hasn’t generated much fresh community chatter in the last 30 days, so this piece leans on accumulated context and the core arguments rather than live reactions. Read it with that in mind.

Why Go, of All Things

The first thing that surprised people was the language choice. TypeScript is a Microsoft project, and Microsoft owns Rust expertise and C#. So why Go?

The answer is structural similarity to the existing code. Today’s TypeScript compiler is written in JavaScript, in a heavily imperative style built around functions and closures. Moving that to a language with strict ownership semantics like Rust would mean rearchitecting the entire codebase. Go, with garbage collection and a deliberately simple syntax, let the team port the existing compiler logic almost line-for-line. They repeatedly framed the project as “a port, not a redesign” — and Go fit that mandate cleanly.

Go also bakes concurrency into the language, which helps with work that parallelizes nicely, like type-checking. And because it compiles to native code, the JavaScript runtime overhead simply disappears.

The 10x Isn’t Marketing

The number everyone latched onto is, of course, 10x. In the team’s published benchmarks, a full build on a massive codebase like VS Code dropped to roughly one-tenth of its previous time.

Concretely: one large project that took 77 seconds under the old compiler finished in around 7.5 seconds on the new one. Editor responsiveness improved sharply too — the speed at which type information loads and autocomplete pops up. That tiny lag you feel after every edit largely goes away.

Why does this matter? Developer productivity ultimately hinges on the speed of the feedback loop. The shorter the gap between hitting save and seeing the result, the longer you stay in flow. The 10x figure isn’t just a faster build — it changes the texture of the work itself.

Let’s Sort Out the Names First

Here’s where things get confusing. The project was initially codenamed “Corsa,” and the development repo shipped publicly as typescript-go. The version where this native compiler officially lands is TypeScript 7.

So what happens to the JavaScript-based compiler we use today? It sticks around as the TypeScript 6.x line for the foreseeable future. In other words, two compilers coexist for a while — the old JS version handling stability and compatibility, the new Go version handling performance. That dual-track setup is a pragmatic move to keep migration risk low.

Not Everyone Cheered

Naturally, the debate ran hot. The most common objection: why build tooling for the JavaScript/TypeScript ecosystem in Go?

Some developers voiced real disappointment. Because the compiler was written in JavaScript, the community found it relatively easy to read the source, contribute, and experiment. A whole class of tools — linters, bundlers, and their type-aware features — was built on top of the compiler’s internal APIs. Once those internals become a native binary, the way you reach them changes.

Another sticking point: “If you were going to do this, wasn’t Rust the better call?” Tools like SWC, esbuild, and Biome had already been attacking the ecosystem’s speed problems with Rust or Go. The team’s answer, repeated often, was that the goal was never a brand-new compiler but a port that preserves existing behavior exactly — and within that constraint, Go was the easiest target to port to. This was less a performance championship than a careful move of proven logic from one house to another.

Why the Ecosystem Is Shaking

Here’s why this doesn’t end as a simple speed bump. The TypeScript compiler was itself a platform. Countless tools were built by peering into its internals.

Editor language servers, type-aware lint rules, documentation generators, all manner of build pipelines — every one of them now has to talk to a native compiler in a new way. The team says it’s preparing a dedicated API layer for exactly this, but tools that leaned heavily on the JS API will need some time to adapt.

So this is a performance upgrade and a realignment of the ecosystem at the same time. Over the next few years, it’s likely to accelerate the broader shift of the JavaScript toolchain toward native.

The Takeaway

TypeScript 7 isn’t just “a faster tsc.” It breaks a long-standing reflex — that tools built for JavaScript should stay written in JavaScript — and crosses a language boundary in the name of performance. Behind the 10x lies careful thinking about portability, compatibility, and the direction of the entire ecosystem.

If your project is large, this change will land as a productivity gain you can actually feel. But one question lingers. As the tools we rely on keep turning into native binaries, how do we protect the openness that once let anyone read and contribute to them? Speed or accessibility — which one gets your weight?