Review of an interview with the author of TypeScript about porting it to Go

#javascript #typescript

I’m excited to share insights from a one-hour interview with Anders Hejlsberg, the creator of TypeScript, about an impressive new port of TypeScript to Go. This development promises significant improvements, and I’d love to walk you through the details!

What could unlock even better performance for Node.js? Let’s explore.

Official Announcement: A 10x Faster TypeScript

Source Code: github.com/microsoft/typescript-go

Here are my notes and reflections based on the interview.

The TypeScript community has long prioritized performance enhancements, often highlighting this need more than requests for new features. It’s inspiring to see this focus come to life.

The team rewrote 80% of the functionality in just six months, starting in August 2024. While features like JSDoc and JSX aren’t supported yet, and the remaining 20% will take a couple more years to refine, this is a promising step forward. For large, established projects, this timeline matters, but new projects—or those not relying on less common features—might adopt the new compiler as early as this year!

Why Go?

While I was writing this article, Anders described his thoughts: https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12466988

Rewriting a project of this scale from scratch wasn’t feasible, so the team chose to port it file-by-file, aiming to keep changes minimal. A key priority was maintaining nearly identical behavior—99.999% of it—to support smooth transitions for development teams.

Go stood out as the ideal choice for several reasons:

It’s designed with performance in mind and operates at a lower level.
It aligns beautifully with TypeScript’s recursive data structures (unlike Rust, for example).
It offers excellent cross-platform support (unlike C#, which was less suitable).

Performance Gains

TypeScript’s current codebase uses a clear, functional approach—simple functions and mostly immutable data structures, avoiding complex OOP or FP abstractions. I really appreciate this thoughtful design.

Immutable data structures are vital for tasks like quickly and safely reloading code during IDE edits, which benefits developers working on real-world products.

Go’s multi-threading capabilities brought an immediate 3x performance boost. Some processes are still limited to four threads, and full parallelization isn’t complete yet. Anders didn’t emphasize this, but I suspect there’s even more potential to unlock.

One challenge with multi-threading was shifting away from relying on single-thread predictability. This sparked my curiosity—sometimes, designs that seem less optimal at first glance can quietly offer advantages. For instance, immutability is naturally thread-safe. Anders noted how single-threaded code could depend on predictable initialization order, which becomes less certain in a multi-threaded setup—an intriguing trade-off to consider.

That said, this shift has led to some divergence from the original codebase, which the team is working diligently to minimize.

Another 3x performance gain comes from structs, which improve memory access and simplify multi-threading. Anders explained that the reduced memory usage isn’t just about easing the load on a developer’s machine—it’s about optimizing individual processes, helping avoid CPU cache limits and performance hiccups.

I do wish there were more progress in JavaScript itself. For example, TC39 paused work on Record & Tuple and is moving slowly on Structs. These could potentially deliver a 5x performance boost for Node.js, and I’d love to see more momentum there. It’s an interesting area to think about as the ecosystem evolves.

Anders also praised Go for its variety of numeric types, contrasting this with JavaScript’s single, bulky number type, where little change seems on the horizon.

Interoperability

Anders highlighted another challenge: TypeScript’s API. While some might say it’s barely there—often extended through creative workarounds in JS—the Go version closes those gaps entirely. The exciting part? With the ecosystem’s need for customization and the compiler’s newfound speed, the team is now focused on building a reliable public interface for external use.

This could also lead to a proper LSP for TypeScript, improving tooling support—a welcome development. They’re even exploring ways to integrate with LLMs, enabling them to better understand code with greater accuracy, rather than just parsing it.

The Future of TypeScript’s Codebase

You might wonder if moving away from TypeScript’s original language would discourage contributors. However, external contributions aren’t a huge factor here, and Go is much more approachable for JavaScript developers than, say, Rust.

One question I’m still pondering: how will they address the lack of dogfooding? I’d be curious to hear more.

Anders reassured us that the original TypeScript codebase could be supported for years, even after a full shift to Go. This feels like a carefully planned strategy, not just an experiment.

Final Thoughts

This interview was truly engaging, offering a glimpse into a thoughtful and ambitious project. I’m encouraged by the team’s commitment to a gradual, considerate migration.

Here’s to hoping we’ll soon see DOOM running on typescript-go!

Let’s Discuss:

I’d love to hear your thoughts in the comments! Imagine you’re starting a new project—would you:

Jump into typescript-go this year with its 10x performance boost?
Wait a couple of years for native ECMAScript structures and use TypeScript with a 5x performance gain?

What would you choose, and why? I’m genuinely curious to see how everyone weighs these options!