TypeScript Is Getting Rewritten in Go. Here's Why That Matters

There's a peculiar problem that happens when you fix something in software: success breeds new problems you never anticipated. TypeScript solved JavaScript's reliability issues so effectively that it expanded the entire category of what JavaScript could be used for—which means TypeScript now faces challenges it was never designed to handle.

The TypeScript team just dropped the beta for version 6, and here's the twist: it's essentially a cleanup operation preparing for version 7, which will be written in an entirely different language. Not Rust, not C++—Go. And this decision reveals something fascinating about where TypeScript is actually struggling.

The success problem

When Microsoft built TypeScript, the goal was straightforward: make JavaScript workable at enterprise scale. As developer Theo Browne explains in his recent breakdown, "TypeScript was built because Microsoft wanted to use JavaScript at Microsoft scale, which might sound like nonsense, but it does make sense when you realize how many millions of lines of code Microsoft puts out every single week."

It worked. TypeScript made JavaScript viable for massive codebases by adding type safety and catching errors before they hit production. But here's where it gets interesting: by solving that problem, TypeScript inadvertently expanded what JavaScript could be used for in the first place.

Before TypeScript, JavaScript had a fairly limited range. You could build small web apps, but anything requiring serious reliability, performance, or scale needed a "real" language. TypeScript pushed that boundary way to the right. Now we have full-stack type safety, TypeScript running on servers, TypeScript in desktop apps via Electron. Someone even built Doom entirely in TypeScript's type system—not the game in TypeScript, but rendering frames of Doom using only the type system, which is Turing complete. (Yes, really.)

The problem? TypeScript solved issues for small web apps, but now those small web apps have become massive TypeScript monoliths. And TypeScript compilation is slow.

The 55,000-line file

Here's a detail that kind of breaks your brain: the majority of TypeScript's type checking happens in a single 55,000-line file. It's 3 megabytes of text. GitHub errors out when you try to view it. Most editors struggle to even open it.

This file is the core of what we think of as "TypeScript"—all that lovely type inference, all those helpful error messages. And it's written in TypeScript itself, which sounds elegant until you realize JavaScript is a terrible language for writing compilers.

"JavaScript strengths around its event loop are great for weird async workloads like requests coming in, database calls being waited for," Browne notes. "It is not good at these types of fixed top bottom workflows like a compiler. It just isn't good at that."

At Twitch, Browne's team rebuilt their web app in TypeScript and React. Two years in, it took 5 minutes from running npm run dev to actually seeing the dev environment. Five. Minutes. That's not a tooling problem—that's a fundamental architecture problem.

Why Go, not Rust?

The decision to port TypeScript to Go is fascinating because Rust seems like the obvious choice for a performance-critical rewrite. Rust is faster, more memory-safe, beloved by systems programmers. So why Go?

The answer comes down to two things: garbage collection and shared memory.

Rust's lack of garbage collection means predictable performance—if something takes 1ms, it always takes 1ms. Go has a garbage collector, which means occasional unpredictable pauses. For real-time systems, that's a dealbreaker.

But for compilers? "Do you know who doesn't care about those random spikes? Compilers," Browne explains. "Compilers don't care about the exact frame the thing is done on. Compilers care about doing things as efficiently as possible, reasonably speaking."

The second reason is multi-threading. TypeScript needs multiple threads editing the same memory simultaneously. Rust's entire safety model fights against this—that's kind of the point of Rust. Go doesn't care. For a compiler that needs to coordinate multiple passes across a massive codebase, Go's flexibility matters more than Rust's guarantees.

The 6-to-7 bridge

So what's TypeScript 6 actually for? It's the last version based on the current JavaScript codebase. Microsoft describes it as "the bridge" to version 7.

The TypeScript team faces a maintenance nightmare: they're building a completely new Go-based compiler that needs to be functionally identical to the existing TypeScript compiler, while simultaneously maintaining the old JavaScript-based version. Every quirk, every edge case, every bit of technical debt in the current version makes keeping these two implementations aligned harder.

TypeScript 6 is about trimming the weird stuff. Better defaults. Cleaner inference rules. Removing legacy behaviors that made sense in 2014 but are just baggage now. The goal is to get version 6 aligned enough with the Go version that by end of year, they can deprecate the JavaScript codebase entirely and go all-in on Go for version 7 and beyond.

The Go version already exists and is being used in production. It's 10x faster than the current TypeScript compiler. It also crashes sometimes and has memory leaks, but that's kinda the point of a beta. The performance gains are real enough that teams are already using it despite the rough edges.

What this means for developers

For most TypeScript users, the version 6 beta won't feel revolutionary. The changes are mostly about alignment, cleanup, and setting up for the future. But version 7? That's where the gains materialize.

Microsoft is focusing on three things: better defaults (both for humans and for AI agents—yes, they're explicitly designing for AI tooling now), dramatically faster type checking, and better error messages when things go wrong.

That last one matters more than you might think. When TypeScript's type inference breaks, the error messages can be incomprehensible. For an AI agent trying to fix code, or a junior dev trying to understand what went wrong, those error messages are the entire interface for learning. Better errors mean TypeScript becomes more accessible, which expands who can use it effectively.

The TypeScript rewrite reveals something about modern software development: success creates new constraints. TypeScript worked so well that it outgrew its own architecture. The solution isn't to abandon it—the ecosystem is too valuable, the developer experience too refined. Instead, you rebuild the foundation while maintaining the surface.

That's a harder problem than starting fresh. But it's also the only way forward when you've become infrastructure.