Assumed audience: Folks who use TypeScript—and especially those with an eye to extensions and integrations with TypeScript.
On the one hand, this announcement is a valuable one: the speed of type checking TypeScript code bases can be a significant hurdle for adoption. I am glad to see the team prioritizing this, because it is really important!
Some questions that immediately come to mind, however:
-
Why Go? Go is a solid language with a lot of real-world use, but it seems like a poor fit in some ways for the kind of thing that TS is and does, not least in that JS-Go interop is not especially clean and that Go is also not particularly easy to integrate with actually-native langauges (C, C++, Rust, Zig), and that its Wasm story is early to say the least.
-
What is the migration story going to be for tools that patch TS? This is closely related to the above. This might seem like a “tough, deal with it” other than the fact that “monkey-patch our public (if unstable) API)” has been the Microsoft-recommended approach for extending TS, given the lack of extensibility in other ways. This is what Svelte, Ember’s Glint, and lots of other tools have had do do for years,1 and that approach very obviously will not work with Go. And directly related to the point above: does the TS team expect the community to rewrite all of those tools in Go?2
-
Will this at least come with a native Language Server Protocol implementation? Some of the above factors could be mitigated by this, and it has been one of the longest-standing challenges for folks looking to integrate.
Suffice it to say I’ll be tuning into the AMA later this week on the TS Discord with considerable curiosity.
Edit, 2025 – 03-11 09:45am: A hypothesis about why the team chose this (zero inside info, just a guess): they could port to Go, keeping the overall architecture basically unchanged for this initial work. Moving to something like Rust would have been a rewrite. I would guess a Rust rewrite would have forced them to revisit their architecture — in many cases significantly so. “Garbage collection or not?” ends up being a really big deal in terms of how your program can naturally be structured.
Edit, 2025 – 03-11 09:55am: this post seems to bear out my above hypothesis pretty cleanly!
Notes
Because the TS team built in native support for JSX and provided no extensibility for parsing, so everybody who had a different templating layer had to build their own — including Vue, Svelte, Angular, and Ember. ↩︎
When the momentum now is very much toward Rust, and many of those tools are using Rust already? ↩︎