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.
The numbers Microsoft published
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.
Why Go, and why not Rust
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.
TypeScript 6 vs TypeScript 7: two compilers, one language
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.
Trying tsgo today
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.
What it means for your build
You do not need to change how you write TypeScript. But the performance shift changes what is practical in your pipeline and your editor.
- CI type-check steps that took minutes on a large monorepo drop toward seconds, making a full type-check on every push cheap rather than something you batch or skip.
- Editor startup on large projects stops being the thing you wait through each morning; autocomplete and error squiggles arrive an order of magnitude sooner.
- Roughly halved memory use means the language service is less likely to fall over on the biggest repositories, where it currently strains the most.
- Your tsconfig.json is intended to keep working, so adopting the native compiler is mostly a matter of swapping the binary, not rewriting configuration.
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.