Microsoft TypeScript Devs Explain Why They Chose Go Over Rust, C#

Microsoft’s Anders Hejlsberg explained that Go was chosen for its TypeScript compiler port because of its native code, garbage collection, and excellent control over memory and data layout.

Last week Microsoft announced that TypeScript’s compiler is being ported to a new programming language — Go. And then a round of discussions kicked off online… Everyone’s fascinated by their high-stakes decision, and a few commenters couldn’t resist second-guessing the development team’s choice of a new programming language.

Why Go? Why not Microsoft’s own C# or the hot language of the day, Rust?

TypeScript‘s developers soon found themselves in kind of ad hoc colloquium taking place on GitHub, Reddit, YouTube, and Hacker News, explaining their decision-making process and all the clear and undeniable advantages of Go. Amid all the back-and-forth discussion, together they offered a surprisingly educational exploration of the various merits of several different programming languages.

And along the way, they even delivered a detailed explanation for why they’ve decided to port TypeScript’s compiler to Go…

But Why Not C#?

TypeScript’s current compiler is written in the TypeScript language. But on Reddit there was a funny yet irrefutable comeback when one commenter suggested that C# “has almost all you need” for rewriting TypeScript code.

“Well you can tell that to the guy who created Typescript and C#, but he disagrees with you.”

Indeed, it’s a question Anders Hejlsberg addressed during a video announcing the move. “Some of you might ask, ‘Well why not my favorite language? Why not C#? Why not Rust? Why not C++?”

Hejlsberg answered that Go was “the lowest-level language we can get to that gives us full, optimized, native-code support on all platforms, great control over data layout, the ability to have cyclic data structures and so forth. It gives you automatic memory management with a garbage collector and great access to concurrency.”

Hejlsberg also addressed the question in a special Zoom interview for the YouTube channel of a monthly TypeScript Meetup in Ann Arbor, Michigan. Hejlsberg described C# as “bytecode-first, if you will.” Plus, when it comes to performance, C#’s ahead-of-time compilation isn’t available on all platforms, and “it doesn’t have a decade or more of hardening… ”

“And then I think Go has a little more expressiveness when it comes to data structure layout and inline structs and so forth.”

But there was also something unique about Microsoft’s original TypeScript codebase for its compiler. While C# is an object-oriented language, TypeScript uses “very few classes,” Hejlsberg said in the Zoom interview. “In fact, the core compiler doesn’t use classes at all…

“Go is functions and data structures, where C# is heavily object-oriented programming (OOP)-oriented. And we would sort of have to switch to an OOP paradigm to move to C#… There’s just more friction in that transition than there is in the transition to Go.”

On Reddit one commenter even collected all the official answers from Microsoft into a handy chart — that Go had a well-tested native-first option supporting all their desired platforms (unlike C#).

Zoom

Why Not Rust?

In a Reddit comment that received 1,305 upvotes, TypeScript development lead Ryan Cavanaugh acknowledged the groundswell of curiosity. “We definitely knew when choosing Go that there were going to be people questioning why we didn’t choose Rust (or others).

“It’s a good question because Rust is an excellent language, and barring other constraints, is a strong first choice when writing new native code.”

Both Rust and Go are good at representing data, have “excellent” code generation tools, and perform well on single-core systems, Cavanaugh wrote. “In our opinion, Rust succeeds wildly at its design goals, but ‘is straightforward to port to Rust from this particular JavaScript codebase’ is very rationally not one of its design goals.

“It’s not one of Go’s either, but in our case given the way we’ve written the code so far, it does turn out to be pretty good at it.”

Cavanaugh shared some insider info: that they did try Rust. But they’d wanted the new codebase to be “algorithmically similar to the current one,” and Rust just wasn’t a fit. “We tried tons of approaches to get to a representation that would have made that port approach tractable in Rust, but all of them either had unacceptable trade-offs (performance, ergonomics, etc.) or devolved into ‘write your own Garbage Collection’-style strategies. Some of them came close, but often required dropping into lots of unsafe code…”

Cavanaugh explains in the project’s FAQ on GitHub that they’d also tried other languages too, and even “did deep investigations into the approaches used by existing native TypeScript parsers like swc, oxc, and esbuild.” Cavanaugh says they reached two important conclusions.

• “Many languages would be suitable in a ground-up rewrite situation.”
• “Go did the best when considering multiple criteria that are particular to this situation…”

On Reddit someone pointed out Go gives “more fine-grained control over memory” — and Ryan Cavanaugh jumped in to agree that Go “has excellent control” over memory allocation. Bypassing Go’s built-in allocator with a pool allocator “is extremely straightforward (and easy to experiment with without changing downstream usage).”

In comparison, Cavanaugh adds, “Rust has better control of ‘When do you free memory,’ but in a type checker there is almost nothing you can free until you’re done doing the entire batch, so you don’t really gain anything over a GC model in this scenario.”

In the FAQ Cavanaugh also applauds Go’s control of memory layout — and that it does all this “without requiring that the entire codebase continually concern itself with memory management.”

So when it comes to Rust, Cavanaugh explained on Reddit that they’d face two options:

• “Do a complete from-scratch rewrite in Rust, which could take years and yield an incompatible version of TypeScript that no one could actually use…”
• “Just do a port in Go and get something usable in a year or so and have something that’s extremely compatible in terms of semantics and extremely competitive in terms of performance.”

In a comment on Hacker News, Cavanaugh reminded readers that in 2022 the SWC (Speedy Web Compiler) project also chose Go for a port of the TypeScript type checker tsc. (Project founder DongYoon Kang noted that tsc “uses a lot of shared mutability and many parts depend on garbage collection. Even though I’m an advocate and believer in Rust, it doesn’t feel like the right tool for the job here.”)

“kdy1 definitely hit on the right general approach with his initial Go port,” Cavanaugh said in a comment on Reddit.

Zoom

Pros and Cons

In the Zoom interview Anders admits that TypeScript has a “much richer” type system than what’s available in Go. But on the other hand, Go “does actually have excellent support for bit-fiddling and packing flags into ints. And in fact it has much, much, much better support than JavaScript for all of the various data types… You can have bytes and short ints and ints and 64-bit ints and what have you, both signed and unsigned… In JavaScript, everything is a floating point number. Period.” He laughs. “I mean, you want to represent true or false? Yeah, that’s eight bytes for you right there…”

Hejlsberg says there’s more than just making use of all the bits in Go. “We can also lay them out as structs — you know, inline, in arrays. And it shows! Our memory consumption is roughly half of what the old compiler was… If you can condense your data structures, you’re going to go faster.”

And here Hejlsberg paused to reflect on what a long, strange trip it’s been, saying he’s often laughed about what he would’ve said if if people had told him, ‘Anders, you’ll be writing compilers in JavaScript for a decade’…

‘You are nuts.’

“JavaScript was never really intended to be the language for compute-intensive, system-level workloads…” he says. “Whereas Go was precisely intended to be that… Go is a system-level tool, and we are a systems-level program.”

Hejlsberg also found himself weighing in on the ‘Why Go’ discussion on GitHub, emphasizing that the decision to use Go “underscores our commitment to pragmatic engineering choices.”

“At Microsoft, we leverage multiple programming languages including C#, Go, Java, Rust, C++, TypeScript, and others, each chosen carefully based on technical suitability and team productivity.”

Celebrate the Strength

As the original designer of C#, Hejlsberg must’ve taken some pride in pointing out that “C# still happens to be the most popular language internally, by far.” Further down, he even emphasized Microsoft remains invested in C# and .NET “due to their unmatched productivity, robust ecosystem, and strong scalability.”

And he said they’d even tried a C# prototype for TypeScript’s compiler, but “Go emerged as the optimal choice, providing excellent ergonomics for tree traversal, ease of memory allocation, and a code structure that closely mirrors the existing compiler, enabling easier maintenance and compatibility.”

Starting from scratch would’ve been an entirely different question, Hejlsberg adds, but “this was not a green field — it’s a port of an existing codebase with 100 man-years of investment…” With a codebase that was “all functions and data structures” — with no classes — Go just turned out to be “more one-to-one in its mapping… Idiomatic Go looked just like our existing codebase, so the port was greatly simplified.”

Hejlsberg used the moment to make the case that “at Microsoft, we celebrate the strength that comes from diversity in programming languages.”

And his comment also closed with some historical perspective. “Let’s be real. Microsoft using Go to write a compiler for TypeScript wouldn’t have been possible or conceivable in years past.” But “over the last few decades, we’ve seen Microsoft’s strong and ongoing commitment to open-source software, prioritizing developer productivity and community collaboration above all.” Today, Hejlsberg argued, Microsoft sought to “empower developers with the best tools available, unencumbered by internal politics or narrow constraints.

“This freedom to choose the right tool for each specific job ultimately benefits the entire developer community, driving innovation, efficiency, and improved outcomes. And you can’t argue with a 10x outcome!”

SHARE THIS STORY