Table of Contents
Your TypeScript build took 89 seconds this morning. Microsoft just made that 8 seconds. That’s not a typo. That’s not a benchmark on a toy project. That’s VS Code’s actual 1.5 million-line codebase running through the new Go-based TypeScript compiler.
Microsoft rewrote tsc from scratch in Go. The project is codenamed Corsa. The binary is called tsgo. It’s available to try right now. And it’s the biggest TypeScript news since strict mode. Here’s what you need to know.
The Problem You’ve Been Living With
If you’ve worked on any TypeScript project over 10,000 lines, you know the feeling. You hit save. You wait. The spinner runs. You lose your train of thought. TypeScript’s type checker is brilliant. It catches bugs before they reach production. But the tool that runs it has always been the slow kid in the toolchain. It’s written in JavaScript, runs on Node.js, and it shows.
On VS Code’s codebase, the old tsc takes 89 seconds to do a full type check. Redux takes 30 seconds. Ant Design takes over a minute. If you’re running a CI/CD pipeline that type-checks every pull request, you’re burning money every single day. Microsoft knew this. And they didn’t tinker around the edges. They burned it down and started over.
What Microsoft Actually Did (And What They Didn’t)
Let’s kill the confusion right now. Microsoft did NOT change the TypeScript language. Your .ts files work exactly the same. Your syntax, your types, your interfaces. All unchanged. You don’t rewrite a single line of code.
What they changed is the compiler. The program that reads your code, checks your types, and spits out JavaScript. Until now, that program was written in TypeScript and ran on Node.js. They ported it to Go. Think of it this way: the rules of the game haven’t changed. The referee is just a lot faster now.
The new compiler is called tsgo. It lives in the typescript-go repo on GitHub. It reads the same tsconfig.json you already have. It produces identical JavaScript output. It’s a drop-in replacement for tsc, and it runs dramatically faster.
The Numbers That Actually Matter for TypeScript 7.0 Go
Here’s what tsgo does on real production codebases. Not benchmarks. Not toy apps.
| Project | Old tsc | New tsgo | Speedup |
| VS Code (~1.5M lines) | 89.0s | 8.74s | 10.2x |
| Redux | Baseline | 60% faster | ~2.5x |
| Ant Design | Baseline | 30% faster | ~1.4x |
| Zod | Baseline | 35% faster | ~1.5x |
And it’s not just speed. tsgo uses 3x less RAM than the old compiler. If you’re paying per gigabyte on GitHub Actions or CircleCI, that’s real money. A mid-sized team running 30 pull requests a day could cut their type-check CI costs by $20 per month. Enterprise teams running 200+ PRs a day? We’re talking $500 to $2,000 a month.
Why Go? (And Why Not Rust?)
Everyone asked this when the announcement dropped. Microsoft chose Go over Rust and C#. Here’s why. Go has built-in concurrency. Goroutines and channels are exactly the right tools for a compiler that needs to parse dozens of files at once. The TypeScript team could write natural concurrent code without fighting an async runtime.
Go is easier to onboard. Rust is fast, but the borrow checker is brutal. New contributors take months to get productive. Go takes weeks. For a project that needs long-term maintenance by a large team, that matters.
Go doesn’t need a runtime you don’t control. C# would have tied the compiler to .NET. The team wanted something cross-platform and easy to distribute. Go produces a single native binary. That’s it. They didn’t pick Go because it’s trendy. They picked it because it’s the right tool for this specific job.
Does This Make Your App Faster?
No. And this is where I see people get confused. Your TypeScript application doesn’t run faster in the browser. The JavaScript your code compiles to is identical. tsgo doesn’t touch runtime performance. Your app’s speed in production is completely unaffected.
What gets faster is your development experience:
- VS Code’s type-checking overlays become near-instant, even in large files
- Your CI pipeline spends less time on every pull request
- Your local TSC –watch doesn’t lag behind your changes
- Your monorepo builds drop from 5 minutes to under a minute
That’s nothing. Flow state is real. Waiting for a build kills it. Getting it back after 90 seconds is hard. Getting it back after 9 seconds is easy.
How to Try tsgo Right Now
You don’t need to wait for TypeScript 7.0. The preview is available today.
Step 1: Install it:
npm install -g @typescript/tsgo
Step 2: Verify it’s installed:
tsgo –version
Step 3: Run it on your project. Navigate to your project root, where tsconfig.json lives
tsgo –noEmit
Step 4: Compare the timing.
time tsc –noEmit
time tsgo –noEmit
Common Mistakes Developers Make With tsgo
Mistake 1: Assuming tsgo is production-ready for everything.
It’s not. Declaration emit (building .d.ts files for libraries) is partial. Custom transformer plugins that hook into the TypeScript compiler API may not work yet. If your project does either of these things, run tsgo in parallel but keep tsc as your primary compiler for now.
Mistake 2: Expecting it to fix slow app performance.
tsgo speeds up compilation. Not execution. If your app is slow at runtime, that’s a different problem entirely.
Mistake 3: Waiting for TypeScript 7.0 before testing.
TypeScript 7.0 is coming later in 2026. But tsgo is available today as a standalone preview. Run it on your project this week and get real numbers from your own codebase.
Mistake 4: Ignoring the CI cost impact.
Most developers think about this in terms of time. Your engineering manager thinks about it in terms of dollars. Run the math on your CI pipeline and bring that number to your next team meeting. It’s a much easier sell than “the builds feel faster.”
Your Action Plan: Start This Week
You don’t need to overhaul anything. Here’s a focused plan you can execute right now.
Day 1: Benchmark your current build.
Run time tsc –noEmit and write down the number. That’s your baseline.
Day 2: Install tsgo and run it.
npm install –save-dev @typescript/tsgo
time tsgo –noEmit
Record your tsgo time. Calculate the improvement. That’s your data.
Day 3: Add tsgo to CI as a parallel check.
Run both tsc and tsgo in parallel on every PR. Compare outputs. If both report zero errors, your project is clean.
Day 4: Share your results.
Drop your before/after numbers in the comments. Tweet them. Bring them to your team. Concrete data is what teams use to make the case for upgrading.
Day 5: Watch the repo.
Star microsoft/typescript-go on GitHub. Turn on release notifications. When TypeScript 7.0 drops, you want to know the same day.
What You Should Do Right Now
If you’re on a large codebase, start testing tsgo this week. Don’t wait for the stable release. Get real data before the migration is mandatory.
If you’re on a smaller project, relax. The improvement lands automatically when you upgrade TypeScript. Nothing special is required.
Either way: pay attention. TypeScript 6.0 RC is shipping now. TypeScript 7.0 is the full Go port. This year is a turning point for how fast TypeScript development feels.
Want the TypeScript 7.0 migration checklist the moment it drops? Subscribe to the Tech With Davis newsletter at techwithdavis.com. I’ll send it straight to your inbox with step-by-step instructions the same day it ships. Drop your current tsc build time in the comments. I’m collecting real-world data from projects of all sizes.
Leave A Reply