tsc is going native

The article A 10x Faster TypeScript by Anders Hejlsberg (Microsoft) includes the following text, as well as a link to the video below,

“[…] we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage. By porting the current code-base, we expect to be able to preview a native implementation of tsc capable of command-line type-checking by mid-2025, with a feature-complete solution for project builds and a language service by the end of the year.”

This port is going to be available very, very soon, probably within the next three months. That’s quite ambitious.

A 10x Faster TypeScript by Anders Hejlsberg (YouTube)

The discussion C# vs. Go Concurrency Model (Reddit) led me to A 10x Faster TypeScript (HackerNews), which included a reference to Why Go? #411 (GitHub), which explains why Go was chosen,

“[…] the most important aspect is that we need to keep the new codebase as compatible as possible, both in terms of semantics and in terms of code structure. We expect to maintain both codebases for quite some time going forward. Languages that allow for a structurally similar codebase offer a significant boon for anyone making code changes because we can easily port changes between the two codebases. In contrast, languages that require fundamental rethinking of memory management, mutation, data structuring, polymorphism, laziness, etc., might be a better fit for a ground-up rewrite, but we’re undertaking this more as a port that maintains the existing behavior and critical optimizations we’ve built into the language. Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.”

The following image, included by a commentator, demonstrates quite nicely how idiomatically similar Go and TypeScript can be.

Go vs. Typescript code

If you read the rest of the justification, the similarities extend to the guts of the respective runtimes and their approach to memory-management and concurrency, but the visual illustration makes it much clearer that this is a port and not a rewrite.

A C# version—with its slightly different concurrency model and also a focus on byte-code rather than native code—would have involved much more change than this.

A version in Rust would have the focus on native-code generation but would have been a complete rewrite, as a lot of the concurrency and data-sharing possible in JavaScript would have to be explicitly allowed or worked around, something that you can’t always (or completely) hide with helper functions. The additional guarantees required in Rust to ensure safety would have to appear explicitly. Sure, you’d have the safety then, but it’s important to remember that, when you’re doing a migration, you should make sure you focus on one migration at a time.

Going from TypeScript to Go will improve some type-safety (though probably not even much) and massively improve speed with a native target. If you want the additional safety of Rust, then you’d do a separate migration step from Go to Rust.

There is another, longer interview video here:

TypeScript is being ported to Go | interview with Anders Hejlsberg by Michigan TypeScript (YouTube)

The interviewer is the guy who just published TypeScript types can run DOOM.