TypeScript is being rewritten in Go, and the payoff is speed the JavaScript-based compiler could never reach. TypeScript 6.0, released in March 2026, is the last version built on the original JavaScript codebase. Its successor, TypeScript 7.0, code-named Project Corsa, is a from-the-ground-up port of the compiler and language service to Go, targeting roughly a 10x speedup, native compiled binaries instead of a Node process, and true shared-memory parallelism. For anyone who has watched tsc crawl through a large monorepo, this is the most consequential change to TypeScript since the language shipped.

  • TypeScript 6.0 (March 2026) is the final release on the JavaScript codebase; 7.0 / Project Corsa moves the compiler to Go.
  • The target is a roughly 10x reduction in build and type-check time, with a native binary that starts instantly instead of booting a Node runtime.
  • Go gives the compiler real threads and shared memory, so type-checking can parallelize in ways JavaScript's single-threaded model blocks.
  • The language and type system are unchanged: same syntax, same .d.ts semantics, a faster engine underneath.
Why a native compiler is faster The JavaScript tsc boots a Node runtime and runs single-threaded; the Go compiler ships a native binary and uses shared-memory threads, targeting about a 10x speedup. tsc on JavaScript Node runtime · 1 thread tsc in Go ~10x faster native binary · threads Same type system, a different engine underneath genztech.blog
Fig 1 · benchmark The gain comes from two structural changes: shipping a native binary instead of booting a Node runtime on every run, and using real threads with shared memory so type-checking can parallelize. Microsoft's early Project Corsa figures target roughly a 10x reduction in wall-clock time.

Why rewrite a compiler that already works?

Because the ceiling is architectural, not incremental. The current tsc is written in TypeScript and runs on Node, which means every build boots a JavaScript runtime and executes on a single thread with garbage-collected objects for every node in the syntax tree. On a small project that is fine. On a large monorepo it turns into tens of seconds of type-checking on every change, and no amount of caching fully hides it. You cannot thread your way out of it either, because JavaScript's concurrency model is not built for the shared-memory parallelism a compiler wants. Porting to Go, a compiled language with real threads, tight memory layout, and no runtime to boot, is the only path to a step-change rather than another 10% shave.

RelatedReact Compiler Is On by Default, Ending Manual Memoization

What changes for developers, and what does not?

The language does not change at all. TypeScript 7.0 keeps the same syntax, the same type inference, the same declaration-file semantics, and the same tsconfig. What changes is how fast you get answers. Editor responsiveness improves because the language service, the thing that powers autocomplete and inline errors, is part of the port, so hovering a type or renaming a symbol in a large project stops stalling. CI gets shorter because type-checking is the slow step in most JavaScript pipelines. The migration risk is low precisely because the type system is being reimplemented to match, not redesigned. Your code compiles the same; it just compiles faster.

Aspecttsc (TS 6, JavaScript)tsc (TS 7, Go)
LanguageTypeScript on NodeGo, native binary
StartupBoots a Node runtimeInstant native start
ConcurrencySingle-threadedShared-memory threads
Target speedupBaseline~10x
Type systemSameSame, reimplemented

How does this fit the 2026 tooling shift?

It is part of a clear pattern: the JavaScript ecosystem is moving its hot paths into fast native languages. Astral rebuilt Python packaging and type-checking in Rust with uv and ty; bundlers and linters have moved to Rust and Go; now the reference TypeScript compiler itself follows. The common thread is that the slow inner loops of developer tooling, parsing, type-checking, bundling, are exactly the workloads where a compiled language with real threads wins big, and the productivity cost of a slow feedback loop finally outweighed the convenience of a single-language toolchain. TypeScript choosing Go rather than Rust was a pragmatic call about porting an existing object-oriented codebase quickly, not a verdict on the languages.

What to watch · 2026-2027
  • Real-world speedups. The 10x figure is on Microsoft's benchmarks. Watch large open-source monorepos publish their own before-and-after numbers.
  • Editor parity. The compiler is the easy half; matching every language-service feature developers rely on is the hard half.
  • Migration friction. Even a matched type system will surface edge cases. How smooth the 6-to-7 jump feels decides adoption speed.

Our take

This is the rare rewrite that is worth the risk, because the bottleneck it targets is real and structural. TypeScript's slowness on large codebases is not a bug you can patch; it is baked into running a compiler on a single-threaded JavaScript runtime, and only a native port removes it. Choosing Go over a more fashionable Rust is a sign the team is optimizing for shipping a faithful port fast rather than winning a language argument, which is the correct instinct when your job is to not break millions of projects. The one caution is expectations: keeping full editor-feature parity is genuinely hard, and the first releases will have rough edges. But the destination is right. A 10x faster tsc changes the daily experience of every serious TypeScript developer, and that is worth a bumpy transition.

Primary sources

Original analysis by GenZTech. Figures current as of July 2026. Source: Microsoft TypeScript Blog.