Recently, the TypeScript team at Microsoft made a decision that stirred up a lot of conversation—and a bit of controversy. That decision? To rewrite the TypeScript compiler in Go, not C#. For some, this triggered questions about Microsoft’s confidence in its own technologies, especially C#. But before jumping to conclusions, it’s important to take a step back and understand what this really means—and what lessons it holds for you as a developer.
The Context: Why Microsoft Chose Go
Microsoft created TypeScript. It powers major products like Visual Studio Code, and as usage has grown, so has the need for performance. The original TypeScript compiler—written in TypeScript—was becoming too slow for large projects. For example, compiling the VS Code project, with over 1.5 million lines of code, took around 77 seconds. Under the new Go-based compiler, that same compilation now takes about 7.5 seconds.
That kind of speed boost is massive. So why not rewrite it in C#? Why choose Go?
The answer lies in real-world software engineering, not headlines. The TypeScript team didn’t want a full rewrite. They wanted a port—something that could preserve existing logic, reduce risk, and dramatically cut down the time to completion. Rewriting everything in C# could take years. Porting to Go will take about one year total. That’s a huge difference in terms of business value.
Why People Reacted So Strongly
When a tech giant like Microsoft chooses a tool outside its own ecosystem, it creates buzz. People meme it, debate it, and use it to feed broader narratives—like “C# is dying” or “Microsoft doesn’t believe in its own language.” But in truth, these hot takes miss the bigger picture.
Instead of leaning into the drama, take this as an opportunity to learn how major engineering decisions get made—especially at the enterprise level.
Key Lessons You Can Take Away
1. Early Decisions Have Long-Term Consequences
The TypeScript team is now living with decisions made years ago. When you’re working on a long-lived codebase, your early architecture, tooling, and design choices can impact what is even possible down the road. That’s why Go was chosen: it enabled porting the existing architecture with minimal disruption.
2. Rewrites Rarely Happen
You may dream of rewriting a codebase from scratch, but in reality, rewrites are expensive, risky, and slow. Microsoft estimated that recreating the TypeScript compiler from the ground up would take 100 man-years. That’s not practical. And it’s a reminder: always write code with maintainability in mind—because you’ll be living with it for a long time.
In reality, rewrites are expensive, risky, and slow.
3. The Best Tool Depends on the Situation
There is no “perfect” language. There is only the right language for this situation. In this case, Go allowed faster performance in a much shorter time frame. Ask yourself: would you rather be 12x faster in 6 years, or 10x faster in 1 year? Sometimes speed of delivery is just as important as the tool itself.
4. Not All Experience Is Transferable
Just because you’ve built something in one language doesn’t mean that approach applies everywhere. Real-world constraints, legacy systems, and cross-team considerations change everything. Keep your opinions flexible—experience matters, but it’s not universal.
5. Time to Completion Is a Key Metric
Shipping matters. Speed to completion isn’t just a nice-to-have—it’s often the difference between success and irrelevance. Don’t underestimate the value of getting working software into users’ hands quickly, even if it means choosing a tool you wouldn’t expect.
6. You Must Be Pragmatic as a Developer
Be a problem solver. No language is a silver bullet. The best developers evaluate the problem, understand the constraints, and choose the best-fit solution—even if it’s not their favorite.
7. Hype and Drama Are Bad Decision-Makers
Don’t follow trends blindly. What’s hyped today might be irrelevant tomorrow. The goal isn’t to chase the flavor of the month—it’s to build the right solution for your product, your users, and your market.
What This Means for C#
Let’s be clear: C# is not going anywhere. Microsoft continues to invest heavily in both C# and .NET. A large portion of its internal and external projects are built on this stack. This decision to use Go was about a specific challenge, with unique constraints—not a signal of abandonment.
So don’t let headlines or hot takes shake your confidence in the tools you use. Instead, let this be a reminder: good developers think critically, act pragmatically, and always look deeper than the surface.
Let’s be clear: C# is not going anywhere.
Leave a Comment