Software Development
TypeScript Goes Native: The 10x Faster Go Compiler tsgo
July 20269 min read
Photo by Nemuel Sereti on Pexels
Microsoft chose Go because the effort is a port that preserves the compiler's existing behavior, not a ground-up rewrite. Maintainer Ryan Cavanaugh noted that idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, and Go offers automatic garbage collection plus fine control over memory layout, which suits the compiler's heavy tree traversal. Rust was rejected because it would force a fundamental rethinking of memory management, turning a manageable port into a multi-year rewrite.
Microsoft reports roughly a 10x speedup on most projects. Type-checking the VS Code codebase of about 1.5 million lines fell from 77.8s to 7.5s, a 10.4x gain, and TypeORM dropped from 17.5s to 1.3s. Editor project-load time falls from about 9.6s to 1.2s, and overall memory use is roughly half the current implementation.
TypeScript 7 is the version number for the new Go-native compiler, codenamed Project Corsa. The existing JavaScript-based compiler continues in parallel as TypeScript 6.x, a bridge release that deprecates some features to align with the native version. The two coexist until the native build reaches sufficient maturity and adoption to stand alone.
Yes, as a preview. Install the @typescript/native-preview package from npm and run the tsgo binary just like tsc, or enable the TypeScript Native Preview extension in VS Code. It is not yet at full feature parity: type-checking is nearly complete and usable, but the language service and the public compiler API are still in progress.
Mostly. The native compiler aims to stay highly compatible with existing tsconfig.json type-checking behavior. The main change is that the deprecated module-resolution modes node and node10 are dropped, so you must switch to bundler or nodenext before testing your project with tsgo.
Photo by Nemuel Sereti on Pexels
Key Takeaway
Microsoft is porting the TypeScript compiler and tooling to Go, a project led by Anders Hejlsberg that it calls a 10x faster TypeScript. Type-checking, editor load, and build times drop roughly tenfold and memory use about halves. The Go-native compiler ships as TypeScript 7, distributed today as the tsgo preview, while the current JavaScript compiler continues as TypeScript 6.
TypeScript's compiler has always been written in TypeScript. That is elegant — the language checks its own source — but it also means every type-check runs on a JavaScript engine, single-threaded, allocating objects the garbage collector must chase. As codebases grew into the millions of lines, that architecture became the ceiling. In March 2025, Anders Hejlsberg, TypeScript's lead architect, announced the fix: a full port of the compiler to Go, under a post bluntly titled A 10x Faster TypeScript.
This is the biggest change to TypeScript's internals since the project began, and it is not a research experiment — it is the declared path to TypeScript 7. The claims are specific and measured, not marketing round numbers, which is exactly what makes them worth reading closely.
Hejlsberg's announcement did not just say faster — it published benchmarks on real, open-source codebases, comparing the current compiler against the Go-native one on identical projects and configs.
| Project | Lines of code | Current tsc | Native tsgo |
|---|---|---|---|
| Visual Studio Code | ~1,505,000 | 77.8s | 7.5s |
| Playwright | ~356,000 | 11.1s | 1.1s |
| TypeORM | ~270,000 | 17.5s | 1.3s |
| date-fns | ~104,000 | 6.5s | 0.7s |
That is a 10.4x speedup on VS Code and 13.5x on TypeORM. The gain developers feel most, though, is not the batch build — it is editor responsiveness. Loading the full VS Code project into the language service falls from about 9.6 seconds to 1.2 seconds, and Microsoft reports overall memory use at roughly half the current implementation. Faster feedback on every keystroke is the real point; the build-time number is just the headline.
The choice of Go set off predictable debate — why not Rust? The maintainers answered directly in a GitHub discussion. The key constraint is that this is a port, not a rewrite: the goal is to preserve the existing compiler's behavior exactly, so the new code needs to mirror the old code's structure. Ryan Cavanaugh explained that idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which keeps the port tractable, while Rust would force a fundamental rethinking of memory management, mutation, data structuring, polymorphism, and laziness. Hejlsberg framed Go as the most native-first language they could adopt while still keeping automatic garbage collection.
The distinction between a port and a rewrite matters for trust. Because the Go compiler is a faithful port of the existing type-checker rather than a new implementation of the type system, the goal is identical type-checking output — the same errors on the same code — just produced roughly ten times faster.
The versioning can confuse people, so here is the model. The existing JavaScript-based compiler continues on the 6.x line, acting as a bridge that deprecates a few features to align with the native build. The Go-native compiler ships as TypeScript 7.0. The two coexist deliberately: Microsoft maintains the 6.x codebase until the native 7.x reaches enough maturity and adoption to stand on its own. So TypeScript 7 is not a new language with new syntax — it is the same language, produced by a new engine.
You do not have to wait for the release to feel the difference. The native compiler is published on npm as the native-preview package, exposing a tsgo binary you run exactly like tsc. There is also a TypeScript Native Preview extension for VS Code that routes the editor's language features through the Go service.
# Add the Go-native compiler preview as a dev dependency
npm install -D @typescript/native-preview
# Type-check with the tsgo binary — used just like tsc
npx tsgo --noEmit --project ./tsconfig.json
# Opt in to the native language service in VS Code
# (.vscode/settings.json, needs the "TypeScript (Native Preview)" extension)
# "typescript.experimental.useTsgo": trueThe preview is not yet at full feature parity. Type-checking is nearly complete and usable for catching errors, but the language service and the programmatic compiler API are still in progress. One config caveat: the native compiler drops the deprecated node and node10 moduleResolution values, so switch to bundler or nodenext before you test.
You do not need to change how you write TypeScript. But the performance shift changes what is practical in your pipeline and your editor.
As of 2026, Microsoft is targeting early-2026 releases for both TypeScript 6.0 and 7.0, with a 7.0 release-candidate milestone tracked in the open. The practical move now is to install the preview, point tsgo at a large project, and watch a type-check that used to take a minute finish before you have looked away. It is the rare performance story where the numbers are not the interesting part — the interesting part is how much slower everything felt once you have seen the fast version.