Why Microsoft Chose Go Over Rust for the TypeScript Compiler Rewrite

Yesterday we reported that Microsoft is ready to port the TypeScript compiler and toolchain to Go, achieving more than a ten‑fold increase in compilation speed across different codebases.

Although many developers praised the announcement, some expressed disappointment that Microsoft chose Go instead of Rust for the port.

A user on the platform summed up the sentiment perfectly: “What’s even more shocking than the 10× speedup is that they didn’t write it in Rust.”

Another commenter noted, “The Java vs C# battle has turned into a Rust vs Go battle. Thanks to TypeScript for making this possible.”

TypeScript’s lead developer Ryan Cavanaugh clarified that the team anticipated debate. He said Rust was considered, but “portability” was the key limitation, ensuring the new codebase remains algorithmically similar to the existing one.

Cavanaugh revealed that the team explored several ways to represent the code for a Rust rewrite, but encountered unacceptable performance and ergonomics trade‑offs, including the need to implement a custom garbage collector, which added complexity.

In contrast, Go provides automatic memory reclamation (garbage collection). Cavanaugh explained that some approaches were close, but usually required inserting a large amount of unsafe code, and Rust lacks enough primitive combinations to ergonomically port JavaScript code.

The team ultimately had two options: rewrite from scratch in Rust, which could take years and result in an incompatible TypeScript version, or build a usable port in Go within a year that is semantically “extremely” compatible while delivering competitive performance.

Cavanaugh also noted that Go, like Rust, offers excellent code generation, data representation, and concurrency primitives.

He added that Rust excels at its design goals, but directly porting this particular JavaScript codebase to Rust is not among them, which is reasonable.

The same reasoning applies to Go, but given the way the team has written code so far, Go turned out to be surprisingly well‑suited for the task.

“We also performed a massive amount of graph processing, especially traversing polymorphic node trees. Go excels at making this ergonomic, particularly when mimicking the JavaScript version of the code,” Cavanaugh wrote in a GitHub article.

Transition to Go Is Much Simpler Than Transition to Rust

In a media interview, TypeScript chief architect Anders Hejlsberg largely reiterated Cavanaugh’s remarks.

He said the only meaningful way to approach the project is to port the existing codebase as‑is. The original design assumes the presence of automatic garbage collection.

Hejlsberg stated, “I think this largely limits our choices and led us to strictly exclude Rust,” highlighting Rust’s lack of automatic memory management.

Hejlsberg also pointed out another challenge: Rust’s strict restrictions on cyclic data structures, which the TypeScript compiler heavily relies on. The system includes abstract syntax trees with parent and child references, mutually referencing symbols and declarations, and naturally recursive types.

“Trying to untangle all of these would make migration to native code extremely difficult,” he said. When considering all requirements, Go emerged as the most suitable language.

It’s worth noting that TypeScript is built on JavaScript. “If you’ve used JavaScript before, you’ll find converting to Go much simpler than converting to Rust,” Hejlsberg added.

He also emphasized that the transition has a very mild impact on the system and does not require a highly ceremonial, “super complex” language.

“I think Rust is closer to the latter,” Hejlsberg concluded.