TypeScript is moving to Go. A few thoughts
A quick note on the native TypeScript port: where the speed actually shows up, why Go made sense to me, and the tooling I'm worried about.

On 11 March Anders Hejlsberg posted A 10x Faster TypeScript: the compiler and language service are being ported to Go (working name Project Corsa), the current JavaScript codebase carries on as the 5.x and 6.x line, and the native one should ship as TypeScript 7. My team chat went very quiet for a minute and then didn't stop for an hour.
I've had a few weeks to poke at the preview on my own projects, and the speed-up on a full type-check is real. It isn't a clean 10x on a codebase my size, but it's big enough that I stopped looking at the decimals. Trying it takes two commands:
npm install -D @typescript/native-preview
npx tsgo --noEmit -p .
What I actually care about more is the editor, though. Most of my day isn't spent running tsc. It's hovering, jumping to definitions, and waiting for the red squiggles to catch up after I rename something in a shared types file, and on the big monorepo at work the language service can take long enough to load that I've gone and made tea. If the editor numbers Microsoft quoted hold up on our repo, that changes how the job feels far more than shaving CI minutes does. (Builds of the app itself won't move much, by the way. Most of us already strip types with esbuild, swc or Turbopack and never use tsc to emit anything.)
People were cross about Go instead of Rust within the hour. The team's reasoning is that this is a port and not a rewrite: they want to move the existing compiler across file by file and keep its structure, so it behaves the same way, and the checker leans heavily on garbage collection and on data structures that point back at each other. Go is happy with both. I write Go most weeks for backend services and that matched my gut, because ported Go tends to read a lot like the code it came from, and someone who knows the old checker should be able to find their way around the new one. Go also gives them cheap shared-memory parallelism, which is a chunk of where the speed comes from.
The thing I'd watch is everything that imports typescript as a library. ts-morph, typescript-eslint's type-aware rules, custom transformers, a lot of codegen, Angular's and Vue's tooling all talk to the compiler's JavaScript API, and you can't require a Go binary. A new API is apparently in the works, but it won't be the same one. Language service plugins in tsconfig are in the same boat, and I've got one on an older project that I'm not at all sure survives.
For now I've added a second script to my side projects so I can compare the two:
{
"scripts": {
"typecheck": "tsc --noEmit",
"typecheck:native": "tsgo --noEmit"
}
}
At work I made a list of everything in our toolchain that imports typescript directly. It was longer than I expected, and I think that list is the real migration, more than the compiler swap itself. Issues go to microsoft/typescript-go if you hit something odd.
First published on my blog. Cover photo: Cephas, CC BY-SA 3.0, via Wikimedia Commons (source).
About the author
- Full stack engineer in London with 5+ years on production web platforms. I lead AI-assisted modernisation at Xanda: React and Go for the UK energy market, a government claims portal, and moving old Java and C++ systems onto the cloud. Outside work I run a small home server behind a Cloudflare Tunnel with a handful of public tools on it: Doorstep (rental alerts across Rightmove, OnTheMarket and OpenRent), SeenSooner (NHS A&E and planned-care waits), GridPulse (live GB grid carbon), Sift (LLM ticket triage that survives model failures) and AI Radar (a news digest written hourly by an n8n workflow). I write here about React and Next.js upgrades, Node, coding with AI agents, and the CVEs I've had to patch. Originals live at blogs.kishankanejiiya.tech.
Comments
Join the discussionNo comments yet. Be the first to comment.




