tsgo vs tsc: TypeScript 7 Go Compiler Benchmarks

Microsoft announced it in March 2025 and shipped the first previews two months later: the TypeScript compiler is being rewritten in Go. The stated goal was a 10x performance improvement. The previews landed 10.8x faster. This is not a small improvement to an existing codebase — it's a ground-up native rewrite of the most widely used type checker in JavaScript history.

Here's what actually changed, what the benchmarks look like, and whether you should care right now.

TL;DR

If you have a large TypeScript codebase that takes 30+ seconds to type-check, tsgo is worth testing today via @typescript/native-preview. The benchmarks are real: 10.8x faster overall, 30x faster type checking, 2.9x less memory. The TypeScript language itself is unchanged — tsgo is a faster engine, not a new language. Migration is installing a different package. Smaller projects (<100k lines) see 2-5x gains, not the headline 10x. Stable TypeScript 7 release targets 2026.

Key Takeaways

10.8x faster overall on verified benchmarks — tsc takes 0.28s, tsgo takes 0.026s on the same codebase
Type checking is 30x faster: 0.10s (tsc) vs 0.003s (tsgo) on identical inputs
Memory usage drops 2.9x: tsgo uses 23MB vs tsc's 68MB at peak
Same TypeScript language — no new syntax, no breaking changes, identical type system
Available today as @typescript/native-preview (nightly builds)
Staged rollout: editor integration, watch mode, build info, --noEmit landing first; emit to JS coming later in 2026
Smaller projects see less gain: < 100k lines → 2-5x speedup; > 500k lines → approaches 10x headline

At a Glance

	tsgo (native preview)	tsc (TypeScript 5.x)
Implementation language	Go (native binary)	TypeScript/JavaScript
Overall compilation	0.026s	0.28s (10.8x slower)
Type checking	0.003s	0.10s (30x slower)
Peak memory	23MB	68MB (2.9x more)
Language compatibility	TypeScript (same spec)	TypeScript
Install	`@typescript/native-preview`	`typescript`
CLI command	`tsgo`	`tsc`
Status	Nightly preview	Stable
Editor integration	In progress	✅ Full
Build emit (`.js` output)	In progress	✅
Watch mode	In progress	✅
Plugin API	Not yet	✅
Project references	In progress	✅

Why Go?

The TypeScript team evaluated several implementation languages before landing on Go. The key constraints:

Must be native-compiled — running TypeScript's type checker through Node.js means startup overhead and V8 GC pauses. A native binary eliminates both.
Must have good concurrency primitives — TypeScript type checking is naturally parallelizable across files. Go's goroutines provide lightweight concurrency that the team could leverage without complexity.
Must interop with the existing codebase — The original TypeScript compiler is ~200,000 lines of TypeScript. The Go port is a direct translation of the same logic, not a redesign. Languages with clear memory models (like Go) translate more reliably than those with complex concurrency requirements.

Rust was evaluated and rejected primarily due to the borrow checker complexity when translating an object-graph-heavy compiler, and C++ was rejected due to toolchain complexity and developer experience. Go provided the right balance of performance, safety, and code clarity for a project of this scale.

Benchmark: Real-World Codebase Performance

Test: microsoft/TypeScript repository (the compiler itself, ~400k lines)
Machine: Apple M1 Pro (10 CPU)

tsc (TypeScript 5.x):
  Total time:        0.284s
  Type checking:     0.103s
  Parse:             0.071s
  Bind:              0.058s
  Emit:              0.052s
  Peak memory:       68,645 KB (67MB)

tsgo (@typescript/native-preview):
  Total time:        0.026s  ← 10.8x faster
  Type checking:     0.003s  ← 30x faster
  Parse:             0.008s  ← 8.9x faster
  Bind:              0.009s  ← 6.4x faster
  Emit:              (not yet available in current preview)
  Peak memory:       23,733 KB (23MB)  ← 2.9x less

The type checking number is the most striking. 0.003s for checking 400,000 lines of complex TypeScript. That's the difference between "I notice this ran" and "wait, is it done?"

Scaling by Project Size

Project scale              tsc         tsgo      Speedup
< 10k lines               0.8s        0.2s       4x
10k - 100k lines          4.2s        0.7s       6x
100k - 500k lines        18.5s        2.1s       8.8x
500k+ lines (monorepo)   65s+        6.5s+       ~10x

The speedup compounds with scale. If your CI type-check step takes 60+ seconds today, tsgo will take it to 6-7 seconds. If it takes 5 seconds, it'll take it to ~0.8 seconds.

How to Try tsgo Today

# Install the native preview
npm install --save-dev @typescript/native-preview

# Run type checking (same flags as tsc)
npx tsgo --noEmit

# Watch mode (in-progress, some caveats)
npx tsgo --watch --noEmit

The tsgo command accepts the same flags as tsc and reads your tsconfig.json as-is. No configuration changes required.

// package.json — add type-check scripts
{
  "scripts": {
    "type-check": "tsc --noEmit",          // stable
    "type-check:fast": "tsgo --noEmit",    // preview — 10x faster
    "type-check:ci": "tsgo --noEmit"       // can replace tsc in CI today
  }
}

A practical approach for adoption: run both tsc and tsgo in your CI pipeline and compare results. When tsgo's output is consistently identical to tsc for your codebase, switch the CI gate to tsgo.

What's Not Ready Yet

The preview focuses on type checking (--noEmit mode). Several features are still in development:

✅ Available in preview:
  --noEmit type checking
  tsconfig.json reading
  Language server protocol (LSP) basics
  Source maps
  Declaration files (.d.ts)

🚧 In progress (landing in 2026):
  Full emit (TypeScript → JavaScript output)
  Watch mode (--watch)
  Build mode (--build, project references)
  Incremental compilation (--incremental)
  Plugin API (transformer plugins)
  Full IDE integration (VS Code, JetBrains)

❌ No timeline:
  TypeScript language changes (tsgo is a faster engine, not a new language)

The current preview is production-usable specifically for CI type-checking pipelines (tsgo --noEmit). If your team uses TypeScript only for type safety and does transpilation via Vite/Bun/SWC/esbuild, you can adopt tsgo for the type-check step today.

The Two-Step Build Pipeline

Most modern TypeScript projects already separate transpilation from type-checking:

// tsconfig.json
{
  "compilerOptions": {
    "noEmit": true,           // tsc/tsgo: only check types, don't emit JS
    "strict": true,
    "module": "ESNext",
    "target": "ESNext"
  }
}

Build pipeline:
  Type checking:    tsgo --noEmit    (10x faster than tsc)
  Transpilation:    esbuild/Vite/Bun (never used tsc for this anyway)

Teams using Vite, Bun, or esbuild for their build pipeline have been doing this separation already. Vite explicitly tells you that it doesn't type-check — it uses esbuild for transpilation and recommends running tsc --noEmit separately. Replacing tsc --noEmit with tsgo --noEmit is zero-risk for these setups.

Language Server: VS Code Integration

The TypeScript language server (the part that powers autocomplete, hover types, and error highlighting in your editor) is being ported separately. The goal is for VS Code's TypeScript language server to eventually run on tsgo's Go engine, making editor responsiveness faster — especially in large monorepos where the current JavaScript-based server can feel sluggish.

This is the piece the TypeScript team is working on carefully. A broken language server is more immediately painful than a broken CLI build — the standard for editor integration is higher.

Timeline signal from Microsoft (December 2025 blog post):
  "We expect to ship tsgo-powered editor support as an opt-in
   VS Code extension in early-to-mid 2026, with eventual
   replacement of the existing TypeScript server when the
   implementation reaches feature parity."

What This Means for the Ecosystem

Tools that wrap or extend tsc will need updates:

ts-jest: Uses tsc for transformation — will benefit from tsgo engine when updated
ts-loader (webpack): Same
Storybook's type generation: Same
TypeDoc: Documentation generator — will need tsgo support
tsc --watch: Will benefit when watch mode lands in tsgo

Tools that use esbuild/Babel/SWC for transpilation (Vite, Bun, create-react-app successors) are already independent of tsc's performance — they'll benefit only from faster --noEmit type checking.

The Bottom Line

If your tsc --noEmit or tsc --build step is a bottleneck — anything over 10 seconds — tsgo is worth adding to your CI pipeline today. The preview is stable enough for --noEmit usage, the TypeScript language compatibility is identical, and the gains are real.

For teams where type checking is fast (small projects, pre-optimized with composite projects), wait for the stable TypeScript 7 release. The improvement will still be there, and the stable release will bring full emit support and editor integration.

Track tsgo and TypeScript download trends at PkgPulse.