Microsoft just did something few developers expected: they're rewriting the TypeScript compiler from JavaScript to Go.
Not a minor optimization. Not a small tweak. A fundamental rewrite that delivers 10x faster performance.
This decision sparked intense debate. Why Go? Why not Rust, which is all the rage right now? Why not C#, Microsoft's own language that was also created by Anders Hejlsberg?
Let's dive deep into what's happening, why it matters, and what it means for you.
The Problem: TypeScript's Growing Pains
Before discussing the solution, we need to understand the problem.
TypeScript has become incredibly popular. According to Stack Overflow's 2024 survey, it ranks among the top 5 most loved programming languages. Adoption has exploded, from small startups to tech giants like Google, Microsoft, and Airbnb.
But this popularity created a new challenge: scale.
Modern codebases are getting massive. VS Code alone has over 1. 5 million lines of TypeScript. Projects like Playwright, TypeORM, and enterprise monorepos can have hundreds of thousands to millions of lines.
The TypeScript compiler, written in JavaScript, started struggling under this weight.
Developers felt the pain daily. Build times stretched to 1-2 minutes for large projects. Editor features like autocomplete and go-to-definition felt sluggish. IDEs consumed gigabytes of RAM. CI/CD pipelines became expensive as build times ballooned.
TypeScript became a victim of its own success.
The Solution: Project Corsa
In early 2025, Microsoft announced Project Corsa, an initiative to port the TypeScript compiler to a native language. The goal was clear: dramatically better performance without changing TypeScript's syntax or semantics.
The language they chose was Go.
The Benchmarks Are Stunning
Let's look at real-world numbers from Microsoft's testing:
| Codebase | Size (LOC) | Old Compiler | Go Compiler | Speedup |
|---|---|---|---|---|
| VS Code | 1,505,000 | 77. 8s | 7.5s | 10. 4x |
| Playwright | 356,000 | 11.1s | 1.1s | 10.1x |
| TypeORM | 270,000 | 17.5s | 1.3s | 13.5x |
| date-fns | 104,000 | 6.5s | 0.7s | 9.5x |
| tRPC (monorepo) | 18,000 | 5.5s | 0.6s | 9.1x |
| rxjs | 2,100 | 1.1s | 0.1s | 11.0x |
We're not talking about 10% or 50% improvements. This is a 1,000% improvement.
For context, compiling VS Code used to take over a minute. Now it completes in 7. 5 seconds. That's the difference between going to make coffee and immediately continuing your work.
Editor experience improved dramatically too. Project load time for VS Code dropped from 9.6 seconds to 1.2 seconds, an 8x improvement. Memory usage decreased by approximately 50%. Autocomplete and error checking feel nearly instant, even on massive projects.
For developers who spend most of their time in an IDE, this is a game changer.
The Big Question: Why Go?
This sparked the most heated debate in the developer community.
Microsoft had options. They could have chosen Rust, currently very popular and known for performance and memory safety. They could have chosen C#, also created by Anders Hejlsberg, the same person who created TypeScript.
But they chose Go. Here's why.
Native Code with Garbage Collection
The TypeScript compiler heavily relies on garbage collection. Its data structures are complex, with many cyclic references and dynamic memory allocation. Go provides a mature, efficient GC while still producing native binaries.
Rust doesn't have a GC. Porting the compiler to Rust would require fundamental rearchitecture, completely changing how memory management works. That's not a port. It's a total rewrite.
Ease of Porting
The TypeScript compiler's structure turned out to be well-suited for 1:1 translation to Go. Many patterns in the JavaScript compiler mapped directly to Go with minimal changes.
Hejlsberg called this a "plug and play replacement": new code that's functionally identical to the old code, just faster.
Excellent Concurrency
Go's goroutines and channels make concurrent programming simple yet powerful. For a compiler that needs parallel operations (type checking across files, project references, incremental builds), this is extremely valuable.
Mature Cross-Platform Support
Go produces native binaries for all major platforms without runtime dependencies. This simplifies distribution and deployment significantly.
Reasonable Learning Curve
The TypeScript team was already familiar with JavaScript. Go's syntax, while different, is relatively straightforward compared to Rust. This accelerated development considerably.
Why Not Rust?
Rust is undeniably on the rise. SWC, Turbopack, Biome: many modern JavaScript tools are written in Rust.
But for TypeScript specifically, several challenges made Rust less suitable.
Rust's ownership model doesn't align well with the TypeScript compiler's architecture, which relies on GC and cyclic data structures. Using Rust would mean writing from scratch, not porting battle-tested code. Hejlsberg noted that a Rust rewrite would be a "multi-year job," while porting to Go could deliver results much faster.
Why Not C#?
This is the most ironic part. Anders Hejlsberg created C#. Microsoft is the company behind C#. Why not use their own language?
The answer is pragmatic. AOT (Ahead-of-Time) compilation in C# isn't as mature as Go across all platforms. There's also a paradigm mismatch: the TypeScript compiler is very functional and uses many structs, while C# is more object-oriented. Go was considered to have "a little more expressiveness" for the compiler's data structure layout needs.
Community Reactions
The announcement triggered diverse responses across the developer community.
Most developers welcomed the change enthusiastically. The reasoning was simple: performance. Build times dropping from minutes to seconds is something that immediately impacts daily productivity. Many praised Microsoft for making a pragmatic decision focused on results rather than getting caught up in programming language politics.
The Rust community voiced disappointment. Some called it a "missed opportunity," arguing that Rust would provide better memory safety and equal or better performance. With tools like SWC proving Rust works for JavaScript tooling, some questioned why Microsoft didn't follow this trend.
The C# community had mixed feelings. Many found it ironic that the creator of C# wasn't using his own language. Some wondered if this signaled something about Microsoft's confidence in C# for these use cases.
Senior developers largely took a pragmatic view. As one put it: "Language choice is an implementation detail. What matters is the result: a faster compiler, better developer experience. Microsoft delivered that."
The Bigger Picture: JavaScript Tooling Goes Native
TypeScript 7 isn't an isolated event. It's part of a massive trend transforming the JavaScript ecosystem: the shift from JavaScript-based tooling to native compilers.
Consider the timeline. From 2016 to 2019, Webpack and Babel dominated, with JavaScript tooling written in JavaScript. In 2020, ESBuild (Go) and SWC (Rust) started gaining traction. By 2021-2022, Next.js and Turbopack adopted Rust-based tooling. In 2023-2024, Vite became the default with a Rust backend in development. Now in 2025, TypeScript itself moves to a native compiler.
The pattern is clear:
| Tool | Language | Function | Speedup vs JS |
|---|---|---|---|
| ESBuild | Go | Bundler | 10-100x |
| SWC | Rust | Transpiler | 20-70x |
| Turbopack | Rust | Bundler | 10x+ |
| Biome | Rust | Linter/Formatter | 25x+ |
| TypeScript 7 | Go | Type Checker/Compiler | 10x |
An interesting trend emerges. Go tends to be chosen when garbage collection is needed and simplicity is prioritized (ESBuild, TypeScript). Rust tends to be chosen when maximum performance and safety are top priorities (SWC, Turbopack, Biome).
Both approaches produce dramatic improvements over JavaScript-based tooling.
What This Means for You
As a TypeScript developer, here's what you need to know.
What stays the same:
TypeScript syntax remains exactly the same. Your . ts and .tsx files work as before. tsconfig.json remains compatible. The entire ecosystem (libraries, frameworks, tools) continues working.
You don't need to learn Go. You don't need to rewrite code. This is a change in implementation, not interface.
What changes:
Build times decrease dramatically. Editor experience becomes more responsive. Memory usage drops. CI/CD becomes faster and cheaper.
Timeline:
TypeScript 6. x is the last version with the JavaScript compiler. TypeScript 7. 0, targeting early 2026, will use the native Go compiler. A transition period will allow both versions to coexist. Preview builds are available now via @typescript/native-preview on npm.
How to try it today:
Install the TypeScript Native Preview VS Code extension, use the tsgo command from the preview package, or try Visual Studio 2026 Insiders which already includes native TypeScript support.
Long-Term Implications
The ripple effects of this change extend far beyond faster builds.
For the JavaScript ecosystem:
When the compiler is 10x faster, frameworks can perform more compile-time analysis. IDE plugins can provide more real-time feedback. Monorepos with hundreds of packages become more manageable. AI-powered tools can perform deeper semantic analysis.
For programming language trends:
Microsoft's decision validates Go's position as a pragmatic systems programming language. It shows that Go isn't just for backend services and CLI tools. It can compete with Rust for certain use cases. It demonstrates that pragmatism (choosing tools that solve problems over what's trendy) still matters.
For developer tooling:
The era of JavaScript-based developer tools may be ending. When TypeScript, the language used to write developer tools, itself moves to a native compiler, it's a strong signal. Performance can't be compromised. Developer experience is paramount. Native compilation is the future.
My Take
This decision exemplifies excellent engineering pragmatism.
Microsoft didn't get caught up in Rust hype (even though Rust is great). They didn't force C# out of loyalty (even though it's their own language). They didn't stick with JavaScript for convenience (even though that's the easier path).
They analyzed the problem, evaluated options, and chose the solution that best fit their specific needs. The result: a 10x performance improvement that will be felt by millions of developers.
Could Rust have achieved similar results? Perhaps. But with a longer timeline and higher risk.
Will this decision satisfy everyone? No. Good engineering decisions rarely do.
What matters is the outcome: a faster compiler, better developer experience, and a more productive ecosystem. From that perspective, TypeScript 7 is a major win for everyone in the JavaScript and TypeScript world.
What Do You Think?
Did Microsoft make the right call choosing Go over Rust or C#?
Have you tried the TypeScript 7 preview? What's your experience been like?
Will this native compiler trend continue, or does JavaScript-based tooling still have a place?
Drop your thoughts in the comments. I'd love to hear your perspective. 👇
If you found this analysis useful, consider following for more deep dives on developer tooling and the JavaScript ecosystem.
Top comments (0)