Microsoft Rewrites TypeScript's Compiler in Go — And the Numbers Are In

The announcement that broke my group chats

If you were anywhere near TypeScript Twitter (or Bluesky, or the various Discords) in March 2025, you saw it: Microsoft was rewriting the TypeScript compiler in Go. Not "considering it" — actually doing it, in the open, with Anders Hejlsberg explaining the reasoning on video. The project's internal codename is "Project Corsa," and in the middle of March 2025, Microsoft introduced "Project Corsa," an initiative that aims to port the TypeScript compiler (tsc) and toolset to native code using Google's Go programming language.

My first reaction was the same as everyone else's: wait, Go? Not Rust? The more I read about the motivations, though, the more it made sense — and now, over a year later, the results are shipping and holding up.

Why rewrite it at all

TypeScript's compiler has been self-hosted (written in TypeScript, running on Node) since practically the beginning. That was fine for a decade, but at the scale of modern monorepos it started to hurt: slow editor startup, slow tsc --noEmit runs, memory ballooning on big projects. Microsoft's own framing of the original pitch was blunt about the goal: the team had begun work on a native port of the TypeScript compiler and tools, and the native implementation would drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage.

Why Go, and not Rust or C#

This is the part that generated the most internet arguing. Rust was the obvious "cool kid" pick given how much of the JS tooling world (SWC, Turbopack, Biome, Rolldown) has already moved there. Instead, Hejlsberg went with Go, explaining it in terms of getting the closest match to TypeScript's existing structure. Go was "the lowest-level language we can get to that gives us full, optimized, native-code support on all platforms, great control over data layout."

Practically, a few things pushed the team toward Go: Go's type system and memory model align well with TypeScript's internal data structures, particularly for cyclic graphs, enabling a more straightforward 1:1 port of the algorithms. Its garbage collector removed an entire category of manual-memory bugs the team didn't want to take on mid-port, and its concurrency primitives were a natural fit for parallelizing type-checking. TypeScript's dev lead, Ryan Cavanaugh, put the tradeoff bluntly on Reddit: a from-scratch Rust rewrite risked taking years and producing an incompatible result, whereas a Go port could preserve semantics almost exactly while shipping on a realistic timeline.

Crucially, this was never a reimagining of the language or the checker's behavior. TypeScript 7 is a complete rewrite of the TypeScript compiler in Go, and it maintains full compatibility with TypeScript 6.0, producing the same type errors, locations, and messages, while leveraging Go's native compilation and concurrency model for significantly better performance. Microsoft described the new codebase's type-checking logic as "structurally identical to TypeScript 6.0" rather than a from-scratch redesign.

The numbers, once it actually shipped

TypeScript 7.0 moved through beta, then a release candidate, then general availability, all under the working binary name tsgo before folding back into the standard typescript package. The benchmarks are the kind of thing that makes you want to upgrade immediately. Microsoft reported that a full build of the VS Code source fell from 125.7 seconds on TypeScript 6 to 10.6 seconds, an 11.9x improvement, while aggregate memory use dropped by around 18 percent, and opening a file with an error in the VS Code codebase, previously about 17.5 seconds, now takes under 1.3 seconds. Other projects showed similar gains: compiling the Visual Studio Code codebase dropped from about 77.8 seconds to 7.5 seconds, a 10.4x improvement, and Playwright fell from 11.1 seconds to 1.1 seconds. Roughly half of that speedup comes from running compiled native code instead of JavaScript on Node, with the rest from shared-memory parallelism across CPU cores that the old single-threaded implementation couldn't exploit.

Before anyone gets carried away, it's worth being precise about what's changing. As one write-up put it, what's actually getting faster is the TypeScript compiler, not the TypeScript language itself or the JavaScript runtime's performance. Your shipped app doesn't run any faster, but every tsc invocation, every editor squiggle, and every CI type-check does.

What this means for the rest of us

Adoption should be close to a non-event for most projects: install the latest typescript package and the binary underneath is now the Go-based compiler. The project began as an experimental native port first announced in March 2025, and had been available to the community as the @typescript/native-preview package, which reached over 8.5 million weekly downloads before the mainline merge. The bigger implication is what this unlocks: near-instant project-wide error lists, deeper refactoring tools, and faster feedback loops for AI coding assistants leaning on the language service for context. It's rare that a decade-old piece of core infrastructure gets a ground-up performance overhaul without breaking things for the people using it daily — which is exactly why this has been one of the most talked-about engineering stories of the year, and why I've been watching every release note since.