Microsoft is rewriting the TypeScript compiler in Go, and the headline number — "10x faster" — has been doing a lot of work in everyone's group chat. The real story is more interesting and more useful than the slogan: a genuinely large performance win, a deliberately narrow scope, and a migration story with a sharp edge that will catch tooling authors who aren't paying attention. Here's what has actually shipped as of mid-June 2026, what hasn't, and what it changes for people who build on TypeScript every day.
The headline: TypeScript is being rewritten in Go
In March 2025, Anders Hejlsberg announced that Microsoft is porting the TypeScript compiler, type-checker, and language service to Go, in a post bluntly titled "A 10x Faster TypeScript". The existing JavaScript-based codebase is codenamed Strada; the Go port is Corsa, and it ships as TypeScript 7.0, developed in the open at github.com/microsoft/typescript-go.
The single most important word is port, not rewrite. This is a structural, near-line-for-line translation of the same compiler — the same type-checking logic, the same inference, the same semantics — moved from JS into Go. They are not redesigning the type system. That's what makes "10x faster with the same behavior" a credible claim rather than a fantasy: you're running the same algorithms on a native, concurrent runtime instead of in a single-threaded JS VM.
Where things actually stand (June 2026)
The timeline matters, because secondary coverage has muddled it:
- TypeScript 6.0 shipped on March 23, 2026 as "the last release based on the current JavaScript codebase" — a one-shot bridge from 5.9, with no 6.1 planned (patch servicing only).
- TypeScript 7.0 Beta landed on April 21, 2026. You can run it today:
npm install -D @typescript/native-preview, thennpx tsgo(it becomestscat stable). Named external testers include Bloomberg, Figma, Google, Slack, and Vercel. - Stable was described as a plan — "within a couple of months" of beta — not a shipped release. As of this writing there is no published RC or GA. If you've seen a confident "TypeScript 7.0 released January 2026" claim, it's wrong; a beta cannot follow a GA.
The repo's own README still carries the disclaimer: "not yet at full feature parity with TypeScript. Bugs may exist." Treat it accordingly.
Decoding the 10x claim
The 10x is real, but you have to say which 10x. It's the full-build type-check time, measured by Microsoft on its own projects. The December 2025 numbers (7.0 vs 6.0) are concrete: VS Code 89.11s → 8.74s (10.2x), Sentry 133.08s → 16.25s (8.2x), TypeORM 15.80s → 1.06s (9.9x), Playwright 9.30s → 1.24s (7.5x). Editor project-load improves roughly 8x; memory drops to about half. So the honest framing is "7.5x–13.5x on type-checking, ~8x on editor load," not a flat 10x — and these are vendor benchmarks; I couldn't find independent replication yet.
Here's the part the slogan hides: tsc usually isn't what emits your JavaScript anymore. Modern toolchains (esbuild, swc, Vite) already strip types without type-checking, so a faster tsc doesn't touch your bundling, your tests, or most of your CI minutes. What it speeds up is the type-check step and the editor — which, to be fair, is exactly where large TypeScript codebases hurt most. Just don't expect your whole pipeline to get 10x faster because one stage did.
Why Go, and not Rust or C#
This question launched a thousand hot takes, and Hejlsberg's actual reasoning is more mundane than tribal. The compiler is a web of mutually-referential nodes — cyclic data structures — which fight directly against Rust's borrow checker. Go is, in his words, "the lowest-level language we can get to" that still offers garbage collection, native binaries on every platform, control over data layout, and easy concurrency. C# was passed over as bytecode-first with non-universal ahead-of-time compilation. And because the existing codebase is written in a functional, struct-heavy style, it mapped cleanly onto Go. As maintainer Ryan Cavanaugh put it, porting this specific codebase to Rust "is very rationally not one of its design goals."
The payoff is concurrency: Go's shared-memory goroutines let the type-checker parallelize in ways that were impractical in single-threaded JS, where cross-thread serialization costs would have eaten the gains.
What stays the same — and what 6.0 changes for you
Because it's a port, type-system semantics are preserved. The parity metric behind the loose "95%+" framing is precise: of roughly 6,000 compiler tests that produce an error under 6.0, 7.0 matches all but 74. That's error-detection parity on the checker — strong, but not "zero differences."
TypeScript 6.0 is the migration on-ramp, and it's the one that can actually break your build today. It flips defaults (strict: true, module: esnext, target: es2025, types: []) and deprecates options the Go compiler won't carry forward: node10 module resolution, es5 target, baseUrl, AMD/UMD/SystemJS modules, and outFile. If your tsconfig leans on any of those, fix them now — that's the work that prepares you for 7.0, and it's independent of the Go port.
The catch builders must know
Here's the edge that the "just point your tools at the fast compiler" crowd will hit: TypeScript 7.0's stable release ships without a stable public API. The programmatic compiler API is explicitly deferred to 7.1 or later. Anything that imports from the typescript package is affected:
- typescript-eslint can't adopt
tsgonear-term. The maintainers list the blockers: ESLint has no async-parser support while tsgo's API will be async, and AST plus type data has to cross the Go/JS boundary. Type-aware linting is being re-platformed in Go (via oxc'stsgolint) — a separate, longer road. - Custom transformers,
ts-loader-style type-checking, and in-browser tooling are in the same boat. Go-to-WASM performance is a known weak spot (flagged publicly by Vite's Evan You), which matters for anything running the compiler in the browser. - The beta itself still has gaps: JS emit reaches only ~ES2021 with no decorator downleveling, watch mode is a prototype, and the language service is incomplete enough that VS 2026 enabled it by default with documented holes — missing IntelliSense in cases, unavailable quick fixes, partial Find All References.
The builder takeaway
Adopt tsgo now as a fast type-check in CI and large monorepos — it's a structural port of the same checker, so its errors should match 6.0, and the speed is genuinely transformative for big codebases and editor responsiveness. But treat 7.0 as a checker upgrade, not a tooling cutover. If any part of your stack imports from the TypeScript package — custom transformers, typed lint rules, type-checking loaders, browser tooling — it can't ride the Go compiler yet.
The pragmatic plan: pin 6.0.x for API consumers, run tsgo in parallel for the speed, and revisit a full migration once 7.1 lands a stable API and the lint/transform ecosystem catches up. And whenever you quote "10x," say which 10x — full-build type-checking, not your whole pipeline. Precision is the whole point of a type system; it should be the whole point of how we talk about one, too.
