Microsoft just did something few developers expected: they’re rewriting the TypeScript compiler from JavaScript to Go.

This isn’t a minor tweak. It’s not just an optimization. It’s a fundamental rewrite that delivers 10x faster performance.

This decision has sparked intense debate in the developer community. Why Go? Why not Rust, which is all the rage right now? Why not C# — Microsoft’s own language, also created by Anders Hejlsberg?

Let’s dive deep.

---

Background: TypeScript’s Performance Problem

Before discussing the solution, we need to understand the problem.

TypeScript has become incredibly popular. According to the Stack Overflow 2024 survey, TypeScript ranks among the top 5 most loved programming languages. Its adoption has exploded — from small startups to tech giants like Google, Microsoft, and Airbnb.

But this popularity brought a new problem: scale.

Modern codebases are getting larger. VS Code alone has over 1. 5 million lines of TypeScript code. Projects like Playwright, TypeORM, and various enterprise monorepos can have hundreds of thousands to millions of lines.

And here’s the problem: the TypeScript compiler, written in JavaScript, started struggling.

Symptoms Developers Experience:

• Long build times — waiting 1-2 minutes to compile large projects became normal
• Sluggish editors — autocomplete, go-to-definition, and error checking feel laggy on large projects
• High memory usage — IDEs can consume gigabytes of RAM for complex projects
• Expensive CI/CD — longer build times mean higher cloud computing costs

In short: TypeScript became a victim of its own success.

---

Microsoft’s 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 existing syntax or semantics.

And the language they chose was Go.

Mind-Blowing Benchmarks

The benchmark results? Stunning.

Codebase	Size (LOC)	Old Compiler (sec)	Go Compiler (sec)	Speedup
VS Code	1,505,000	77. 8	7.5	10. 4x
Playwright	356,000	11.1	1.1	10.1x
TypeORM	270,000	17.5	1.3	13.5x
date-fns	104,000	6.5	0.7	9.5x
tRPC (monorepo)	18,000	5.5	0.6	9.1x
rxjs	2,100	1.1	0.1	11.0x

Not a 10% or 50% improvement — 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.

Not Just Compile Time

Performance improvements don’t stop at compile time. The editor experience also improved dramatically:

• Project load time for the VS Code codebase dropped from ~9. 6 seconds to ~1.2 seconds (8x faster)
• Memory usage reduced 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 is the question that sparked the most heated debate in the developer community.

Microsoft had many choices. They could have chosen Rust — a language that’s currently very popular and known for its performance and memory safety. They could have chosen C# — a language also created by Anders Hejlsberg, the same person who created TypeScript.

But they chose Go. Why?

Technical Reasoning from the TypeScript Team

Anders Hejlsberg, TypeScript’s lead architect, explained several key reasons:

1. 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 and efficient GC while still producing native binaries.

Rust, on the other hand, doesn’t have a GC. Porting the compiler to Rust would require fundamental rearchitecture — completely changing how memory management works. This wouldn’t be a port, but a total rewrite.

2. Ease of Porting

The TypeScript compiler’s code structure turned out to be very suitable for 1:1 translation to Go. Many patterns in the JavaScript compiler could be directly mapped 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.

3. Excellent Concurrency

Go is famous for its simple yet powerful concurrency model: goroutines and channels. For a compiler that needs to perform many parallel operations (type checking across multiple files, project references, incremental builds), this is extremely valuable.

4. Mature Cross-Platform Support

Go produces native binaries for all major platforms (Windows, macOS, Linux) without runtime dependencies. This simplifies distribution and deployment.

5. Reasonable Learning Curve

The TypeScript team was already familiar with JavaScript. Go, while different, has relatively straightforward syntax compared to Rust. This accelerated the development process.

Why Not Rust?

Rust is indeed on the rise. Many modern JavaScript tools are written in Rust: SWC, Turbopack, Biome, and more.

But for the TypeScript compiler specifically, there were several challenges:

• Rust’s ownership model doesn’t align well with the TypeScript compiler’s architecture, which relies on GC and cyclic data structures
• Rewrite vs Port — using Rust would mean writing from scratch, not porting battle-tested code
• Timeline — Hejlsberg noted that a Rust rewrite would be a "multi-year job", while porting to Go could deliver results 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
• 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

---

Developer Community Reactions

As expected, this decision triggered various reactions.

The Positive Camp

The majority of developers welcomed this change enthusiastically. The reason is simple: performance.

"Finally! 10x faster build times will immediately impact daily productivity."

"Microsoft made a pragmatic decision. They didn’t get caught up in programming language wars but focused on results."

Developers working on large projects were especially excited. They’ve felt TypeScript’s performance pain points for years.

The Critical Camp

However, there was also criticism, particularly from the Rust and C# communities:

From the Rust community:

"This is a missed opportunity. Rust would provide better memory safety and equal if not better performance."

"With SWC and other tools already proving Rust works for JavaScript tooling, why isn’t Microsoft following this trend?"

From the C# community:

"It’s ironic that the creator of C# isn’t using his own language. Does this signal something about Microsoft’s confidence in C#?"

"This is a missed opportunity to showcase C#’s capabilities in a new domain."

The Pragmatic Perspective

Many senior developers took a middle ground:

"Language choice is an implementation detail. What matters is the result: a faster compiler, better developer experience. Microsoft delivered that."

"The Go vs Rust vs C# debate is academically interesting, but as an end user, I only care whether my IDE becomes more responsive. And the answer is: yes."

---

The Bigger Trend: JavaScript Tooling Goes Native

TypeScript 7 isn’t an isolated phenomenon. It’s part of a larger trend transforming the JavaScript ecosystem: the shift from JavaScript-based tooling to native compilers.

Timeline of the Shift

• 2016-2019: The Webpack and Babel era — JavaScript tooling written in JavaScript
• 2020: ESBuild (Go) and SWC (Rust) start gaining popularity
• 2021-2022: Next. js and Turbopack adopt Rust-based tooling
• 2023-2024: Vite becomes the default, with a Rust backend (Rolldown) in development
• 2025: TypeScript itself moves to a native compiler

Tools Comparison

Tool	Language	Function	Speedup vs JS-based
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

Emerging Patterns

There’s an interesting pattern here:

• 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 the top priorities (SWC, Turbopack, Biome)

Both are valid. Both produce dramatic improvements over JavaScript-based tooling.

---

What This Means for Developers

As a TypeScript developer, what do you need to know?

What Stays the Same

• TypeScript syntax remains exactly the same
• .ts and .tsx files remain the same
• tsconfig.json remains compatible
• Ecosystem (libraries, frameworks, tools) continues to work

You don’t need to learn Go to use TypeScript 7. You don’t need to rewrite your code. This is a change in implementation, not interface.

What Changes

• Build times decrease dramatically
• Editor experience becomes more responsive
• Memory usage is lower
• CI/CD becomes faster and cheaper

Timeline and Migration

• TypeScript 6. x is the last version with the JavaScript compiler
• TypeScript 7. 0 (target: early 2026) will use the native Go compiler
• Transition period will be available where both versions can be used
• Preview builds are available now (@typescript/native-preview on npm)

How to Try It Now

You can try the new compiler in several ways:

1. VS Code Extension: Install the TypeScript Native Preview extension
2. CLI: Use the tsgo command from the @typescript/native-preview package
3. Visual Studio 2026 Insiders: Already includes native TypeScript support

---

Long-Term Implications

For the JavaScript Ecosystem

TypeScript 7 will accelerate development across the entire 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. This shows that:

• Go isn’t just for backend services and CLI tools
• Go can compete with Rust for certain use cases
• Pragmatism (choosing tools that solve problems, not what’s most trendy) is still valued

For Developer Tools in General

The era of JavaScript-based developer tools may be coming to an end. When TypeScript — the language used to write developer tools — itself moves to a native compiler, it’s a strong signal that:

• Performance cannot be compromised
• Developer experience is a priority
• Native compilation is the future of tooling

---

My Take

I see this decision as an example of excellent engineering pragmatism.

Microsoft didn’t get caught up in:

• Rust hype (even though Rust is great)
• Loyalty to C# (even though it’s their own language)
• JavaScript status quo (even though that’s the easier path)

They analyzed the problem, evaluated the 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. But good engineering decisions rarely satisfy everyone.

What matters is the outcome: a faster compiler, better developer experience, and a more productive ecosystem.

And from that perspective, TypeScript 7 is a major win for all JavaScript and TypeScript developers.

---

TL;DR

• TypeScript 7 compiler is being rewritten from JavaScript to Go — codenamed "Project Corsa"
• 10x performance improvement — compiling VS Code from 77 seconds to 7.5 seconds
• Why Go? — Mature GC, ease of porting, excellent concurrency, cross-platform support
• Why not Rust? — Would require a total rewrite, not a port; timeline too long
• Why not C#? — AOT not as mature as Go, paradigm mismatch
• For developers: No syntax changes, just dramatically better performance
• Timeline: TypeScript 7.0 targets early 2026, preview available now
• Bigger picture: Part of the trend of JavaScript tooling moving to native compilers

---

What Do You Think?

Did Microsoft make the right call choosing Go?

Have you tried the TypeScript 7 preview? What’s your experience?

Will this native compiler trend continue, or does JavaScript-based tooling still have a place?

Drop your thoughts in the comments 👇

---

Enjoyed this read? Follow for more deep dives on developer tooling and ecosystem news.

---

References:

• TypeScript Official Blog: A 10x Faster TypeScript
• TypeScript Blog: Progress on TypeScript 7 - December 2025
• The New Stack: Microsoft TypeScript Devs Explain Why They Chose Go Over Rust, C#
• Visual Studio Magazine: Microsoft Ports TypeScript to Go for 10x Native Performance Gains
• DevClass: TypeScript compiler ported to native code
• LogRocket: TypeScript is getting a 10x faster compiler
• AppSignal: The Performance Revolution in JavaScript Tooling