Anders Hejlsberg discusses the decision to port the TypeScript compiler to Go, explaining the performance benefits and language trade-offs involved.
You're about to see concurrent 10x performance on your type checking with half the memory and much faster editor startup. The TypeScript team has been porting the project to Go for the past 8 months.
devblogs.microsoft.com/typescript/typescript-native-port/
In this interview with Anders Hejlsberg, co-creator and lead architect of TypeScript, we tried to ask questions that would be valuable to library authors, power users, and compiler contributors.
If you have any questions, you should join the AMA on the TypeScript Community Discord 10 AM PDT | 5 PM UTC on March 13th.
in this episode...
Introducing Anders
codename Strada and Corsa
whose idea was Corsa?
regarding other attempts (e.g. stc by DongYoon Kang)
discussions within the team about performance and scalability
it started in August 2024
"we realized, we can get to 10x with this!"
what was the general feeling on the team?
unprecedented move to "eject" from being self-hosted
there may always be some parts written JavaScript
why not Rust?
rational for why it has to be a garbage collected language
re: Rust's constraints: borrow checker, cyclic data structures
adding it all up: Go makes a lot of sense
JavaScript has a lot more in common with Go than Rust
why not C#?
the current codebase is written in a functional style
Strada's extensive use of flag packing with TypeScript Enums
typescript-go's memory consumption is HALF (!!) (while also being 10 times faster)
has spending so much time writing Go had any influce on TypeScript?
JavaScript is a very strange language to write a compiler in in the first place
ensuring a smooth transition (in absence of a language spec)
the AST will not change
library authors will not have to maintain two versions of their types
all 20,000 conformance tests already run without crashing
what do you foresee being the toughest challenges ahead?
challenge: deterministic ordering of type union members in a multi-core environment
largest challenge is providing a modern API to the existing codebase
what about the cross-language connection points for the API? WebAssembly? Rust bindings?
strengthening the Language Server Protocol
how long will the existing codebase be maintained after typescript-go is GA?
typescript-go is expected to be ready to use by the end of 2025, if not much sooner
will the Go and TypeScript codebases be merged, or stay separate?
what will happen to existing PRs?
will type-aware tooling also get a 10x speed up?
how hard was it to add concurrency to the type checker?
the current codebase make heavy use of immutability and structural sharing
why shared memory concurrency is so important to this codebase (something Go is excellent at)
adding concurrency in typescript-go was like 10 lines of code (!!!)
b
Why it's here
3 people recommend this
What people say. Recommended for its deep dive into why the TypeScript team chose Go over Rust or C# for their compiler port.
Moments people linked to
d
duckerudeon Hacker News • Recommends
On “A 10x Faster TypeScript”
Anders Hejlsberg explains here: link to this video . TL;DW: - C# is bytecode-first, Go targets native code. While C# does have AOT capabilities nowadays this is not as mature as Go's and not all platforms support it. Go also has somewhat better control over data layout. They wanted to get as low-level as possible while still having garbage collection. - This is meant to be something of a 1:1 port rather than a rewrite, and the old code uses plain functions and data structures without an OOP style. This suits Go well while a C# port would have required more restructuring.
If you are wondering why not Rust instead of Go, they outline why Rust was not chosen. This is a port not a reimplementation. Many of the data structures can not easily be ported to Rust, such as Nodes with cyclic dependencies. Check the longer interview here: link to this video Also, I think the discussion on esbuild's choice of language applies here as well as it has a large similarity. You can find it here on hn
If anyone wants the actual answer why Go over Rust
[video
tl:dw;
* They made an informed decision after evaluating multiple languages, including Rust and C#, ultimately choosing Go.
* It was crucial to perform a port rather than a full rewrite, as TypeScript has many built-in nuances. A rewrite would risk breaking "features" that users rely on.
* Their TypeScript code relied heavily on cyclic graphs and was designed with the expectation of automatic garbage collection.
* Go was chosen in part because it shares more similarities with TypeScript than Rust, making the transition smoother.
They discussed about it in a couple of interviews and on Github
https://github.com/microsoft/typescript-go/discussions/411
link to this videolink to this video
Dimitri from Michigan TypeScript asked Anders the same thing in their interview and I thought the exchange was pretty informative. He says it better than I could so I'll just link it: link to this video
Anders answers that question here - link to this video Transcript: "But I will say that I think Go definitely is much more low-level. I'd say it's the lowest level language we can get to and still have automatic garbage collection. It's the most native-first language we can get to and still have automatic GC. In contrast, C# is sort of bytecode-first, if you will. There are some ahead-of-time compilation options available, but they're not on all platforms and don't really have a decade or more of hardening. They weren't engineered that way to begin with. I think Go also has a little more expressiveness when it comes to data structure layout, inline structs, and so forth."
link to this video19:14 why not C#? Dimitri: Was C# considered? Anders: It was, but I will say that I think Go definitely is -- it's, I'd say, the lowest-level language we can get to and still have automatic garbage collection. It's the most native-first language we can get to and still have automatic GC. In C#, it's sort of bytecode first, if you will; there is some ahead-of-time compilation available, but it's not on all platforms and it doesn't have a decade or more of hardening. It was not geared that way to begin with. Additionally, I think Go has a little more expressiveness when it comes to data structure layout, inline structs, and so forth. For us, one additional thing is that our JavaScrip…
On “Past, present, and future of Sorbet type syntax”
…I prefer C# to typescript or ruby _personally_ for most tasks, I don't think it's perfect, nor is it likely a good crib-sheet for historically dynamic languages looking to add a bit of static typing - at least, IMHO. Bit of a tangent, but there was a talk by anders hejlsberg as to why they're porting the TS compiler to Go (and implicitly not C#) - link to this video - I think it's worth recognizing the kind of stuff that goes into these choices that's inevitably not obvious at first glance. It's not about the "best" lanugage in a vacuum, it's a about the best tool for _your_ job and…
On “Type-constrained code generation with language models”
Hejlsberg mentioned the ability to quickly provide accurate type information to LLMs as one of the reasons for rewriting tsc into Go: link to this video
