TypeScript's Compiler Is Being Rewritten in Go. I Have Mixed Feelings.

I ran tsc --noEmit on Ouija last Tuesday. 14,138 lines of TypeScript across 7 packages. It took 11 seconds. Not terrible. Not great. The kind of time where you alt-tab to Slack, read half a message, then forget what you were compiling.

Then I installed the tsgo preview and ran it again. 3.4 seconds.

That felt good. Genuinely good. But the more I read about this TypeScript Go rewrite, Project Corsa, the less sure I am that speed is the whole story.

My TypeScript Footprint

I should be the target audience for this rewrite. I run TypeScript everywhere. Engram, my memory engine for AI agents, is TypeScript from top to bottom. Ouija, the kanban pipeline automation I've been building this year, is a 7-package TypeScript monorepo with 316 tests. My MCP servers (six of them, running daily) are all TypeScript. My portfolio runs on Next.js with the App Router. Even the tooling around this blog is TypeScript.

When Anders Hejlsberg announced the Go rewrite, my first reaction was excitement. Build times are the tax you pay for type safety, and I'd been watching that tax grow as my projects got bigger. ESBuild proved Go could make JavaScript tooling 100x faster. SWC proved Rust could do the same. TypeScript was the holdout.

So yeah. I wanted the speed.

The 10x Speed Claim vs. My Real Numbers

The headline number is 10x. Microsoft's benchmark took VS Code's TypeScript codebase from 77.8 seconds to 7.5 seconds. That's not marketing. That's a real project with millions of lines of code.

But here's what the migration guides bury in paragraph nine: that 10x number is for massive codebases. VS Code-scale. Google-scale. For projects my size, the gain is closer to 2-5x. Ouija went from 11 seconds to 3.4. That's 3.2x. My portfolio build barely changed because Next.js already uses SWC for transpilation, so TypeScript type-checking was never the bottleneck.

I'm not complaining about 3x faster. 3x is great. But I expected 10x because that's what every article leads with, and I want to be honest about what most developers will actually see.

The memory improvement matters more than I expected, though. Running tsc in a 512MB Docker container for CI used to be a coin flip. Sometimes it finished. Sometimes it OOM-killed halfway through. The Go compiler uses roughly half the memory. That quietly fixed a real problem in my GitHub Actions pipeline for Engram without me changing a single line of config.

What Nobody's Talking About: The Plugin API

Here's where my feelings get complicated.

GitHub issue #516 on microsoft/typescript-go is titled "Transformer Plugin or Compiler API." It was opened in March 2025. As of today, it's still open. 29 thumbs-up. No timeline for a replacement.

Jake Bailey from the TypeScript team responded directly: "Go is a statically compiled language without good plugin support; porting your code to Go is unfortunately not going to be a solution."

Let that sink in. The compiler API that Angular's ngc, Vue's compiler, ts-morph, ts-patch, and hundreds of community tools depend on? It's gone. Not deprecated. Not migrated. Gone. The TS team says they're "working on" a new cross-language API, probably via gRPC or IPC. But "working on it" is not a migration path.

One comment on the issue stuck with me: "I was pretty happy when the Go port was announced, then I remembered I'm the one keeping the infra."

That captures it. The people building tools on top of TypeScript are celebrating the speed with one hand and panicking about extensibility with the other.

I maintain custom type generation scripts for my MCP server tooling. Nothing fancy. TypeScript transformers that generate types from schemas so I don't hand-write interface definitions for every tool. That workflow breaks with tsgo. Not "might break." Breaks. There's no Go equivalent of ts.createProgram that I can call from my Node.js build scripts.

TypeScript 6.0: The Bridge With No Return Lane

TypeScript 6.0 is the "bridge release." It introduces deprecation warnings that become hard errors in 7.0. --target es5 is deprecated (the error message literally says "will stop functioning in TypeScript 7.0"). Several other legacy options are getting the same treatment.

The unusual part: TypeScript 6.0 exists to prepare you for 7.0. There's no indication of a 6.1. The bridge has one lane and it only goes forward. You either migrate to 7.0 or you stay on 6.0 indefinitely. And while the tsconfig deprecations are well-documented, the plugin migration has no official tooling. If your build depends on custom transformers, you're on your own.

For my projects, the config changes are fine. I already use strict mode. I don't target ES5. But I know teams that do. The timeline feels aggressive for an ecosystem this large.

The Go Rewrite Kills Self-Hosting

This one surprised me. TypeScript is becoming the first major language I know of that's actively moving away from a bootstrapping compiler. Every other self-hosted language treats "compiler written in itself" as a point of pride. TypeScript is trading that for performance.

The pragmatic argument is obvious: Go is faster, so the compiler should be Go. But the second-order effect is that the TypeScript team will write less TypeScript in their daily work. Less dogfooding. Less direct feedback loop about what it's like to actually use the language they build. John Reilly wrote about this and called it the aspect that gave him "the most anxiety." I share that.

There's also the contribution angle. Right now, if you want to fix a bug in the TypeScript compiler, you need to know TypeScript. After the rewrite, you need to know Go. How many TypeScript developers also write Go? The Venn diagram isn't empty, but it's a lot smaller than "everyone who uses the language."

This is the part I keep coming back to. JavaScript developers built the modern web's tooling stack by contributing to tools written in JavaScript. Webpack, Babel, ESLint, Prettier, TypeScript itself. The tools were accessible because they matched the language. The Go rewrite breaks that loop. It turns the compiler into a black box for the majority of the community.

The Bigger Pattern

TypeScript isn't doing this alone. Ladybird rewrote in Rust. Cloudflare built a Next.js replacement with native compilation. Biome replaced ESLint and Prettier in Rust. Oxc, Rspack, Turbopack. The entire JavaScript toolchain is being rewritten in languages JavaScript developers don't write.

I already switched to Biome for linting and formatting because it's just faster. And I'll adopt tsgo for type-checking because 3x faster is 3x faster. But each migration moves another piece of the ecosystem out of community reach. The tools get faster. The community gets further from the machinery.

I'm not sure this is a bad thing. Performance matters. Developer experience matters. And maybe the era of "tools should match the language they serve" was always a nice-to-have that couldn't survive at scale.

But I notice it. And I think more people should.

What I'm Actually Doing

I installed @typescript/native-preview and have been running tsgo alongside tsc on my projects for two weeks. Here's where I landed:

Engram: Works fine. No custom transformers, no compiler plugins. Pure speed win.

Ouija: Works with one exception. A build script that calls ts.createSourceFile to parse generated code needs a rewrite. Not the end of the world, but not "zero-effort migration" either.

MCP servers: Four of six work. Two use type generation that depends on the compiler API. I haven't figured out the workaround yet.

Portfolio (Next.js): No difference. SWC already handles the hot path.

So my migration is mostly painless. But "mostly" is doing a lot of work in that sentence. And I'm one person with mid-size projects. I don't envy the Angular team right now.

The Honest Take

The Go rewrite is the right call for performance. I believe that. 3x faster on my projects, 10x on huge ones, half the memory. Those numbers hold up.

But I wish the conversation was more honest about the cost. The plugin API has no replacement timeline. The community can no longer contribute to the compiler in the language the compiler serves. And the bridge from 6.0 to 7.0 has no lane for the tools that made the ecosystem what it is.

I'll migrate. I'm already migrating. But I'm doing it with open eyes, not with the "just upgrade and everything gets faster" story that dominates every article about this right now.

The speed is the headline. The extensibility loss is the story.