Why Microsoft's Developers are Porting TypeScript to Go (infoworld.com) 22
Tuesday Microsoft "surprised everyone," writes Neowin, "by announcing a new change that will radically improve TypeScript performance" — porting TypeScript to Go.
InfoWorld writes that "The initiative promises dramatic improvements in editor startup speed, build times, and memory usage, making it easier to scale TypeScript to large code bases, Microsoft said." Microsoft's TypeScript team expects to be able to preview command-line type-checking in Go-based tsc by mid-2025, and to deliver a feature-complete Go implementation of TypeScript by the end of the year. [You can build and run the Go code now from Microsoft's new working repository.] Developers who use Go-based TypeScript in the Visual Studio Code editor will feel the increased speed in the editor, Microsoft said. The company promises an 8x improvement in project load times, instant comprehensive error listings across entire projects, and greater responsiveness for all language service operations including completion lists, quick information, go to definition, and find all references. The new TypeScript will also support more advanced refactoring and deeper insights that were previously too expensive to compute, the company said.
Microsoft believes native Go implementations reduce build times by up to 10x, notes Neowin. But "Developers can expect TypeScript 6.0 to have some deprecations and breaking changes to support the upcoming Go-based version." Later this year, Microsoft will be releasing this new native Go implementation as TypeScript 7.0. The current JS-based TypeScript codebase will continue development into the 6.x series until TypeScript 7+ reaches sufficient maturity and adoption, since some projects may depend on certain API features, legacy configurations, or other things that are not supported by TypeScript 7+.
TypeScript's original creator Anders Hejlsberg recorded an announcement video — and also shared his thoughts in a GitHub discussion titled simply... "Why Go?" The TypeScript compiler's move to Go was influenced by specific technical requirements, such as the need for structural compatibility with the existing JavaScript-based codebase, ease of memory management, and the ability to handle complex graph processing efficiently. After evaluating numerous languages and making multiple prototypes — including in C# — Go emerged as the optimal choice...
Let's be real. Microsoft using Go to write a compiler for TypeScript wouldn't have been possible or conceivable in years past. However, 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. Our goal is 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!
Hejlsberg also addressed their choice of Go in an online interview with the Michigan TypeScript meetup.
InfoWorld writes that "The initiative promises dramatic improvements in editor startup speed, build times, and memory usage, making it easier to scale TypeScript to large code bases, Microsoft said." Microsoft's TypeScript team expects to be able to preview command-line type-checking in Go-based tsc by mid-2025, and to deliver a feature-complete Go implementation of TypeScript by the end of the year. [You can build and run the Go code now from Microsoft's new working repository.] Developers who use Go-based TypeScript in the Visual Studio Code editor will feel the increased speed in the editor, Microsoft said. The company promises an 8x improvement in project load times, instant comprehensive error listings across entire projects, and greater responsiveness for all language service operations including completion lists, quick information, go to definition, and find all references. The new TypeScript will also support more advanced refactoring and deeper insights that were previously too expensive to compute, the company said.
Microsoft believes native Go implementations reduce build times by up to 10x, notes Neowin. But "Developers can expect TypeScript 6.0 to have some deprecations and breaking changes to support the upcoming Go-based version." Later this year, Microsoft will be releasing this new native Go implementation as TypeScript 7.0. The current JS-based TypeScript codebase will continue development into the 6.x series until TypeScript 7+ reaches sufficient maturity and adoption, since some projects may depend on certain API features, legacy configurations, or other things that are not supported by TypeScript 7+.
TypeScript's original creator Anders Hejlsberg recorded an announcement video — and also shared his thoughts in a GitHub discussion titled simply... "Why Go?" The TypeScript compiler's move to Go was influenced by specific technical requirements, such as the need for structural compatibility with the existing JavaScript-based codebase, ease of memory management, and the ability to handle complex graph processing efficiently. After evaluating numerous languages and making multiple prototypes — including in C# — Go emerged as the optimal choice...
Let's be real. Microsoft using Go to write a compiler for TypeScript wouldn't have been possible or conceivable in years past. However, 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. Our goal is 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!
Hejlsberg also addressed their choice of Go in an online interview with the Michigan TypeScript meetup.
Previous implementation was JavaScript (Score:4, Interesting)
That's the first question I asked when I read the summary here.
(I guess just about any compiled language would be faster than JavaScript...)
Re: (Score:2)
Came here to ask this.
So, what's the runtime compiled to? Object code? Assembler?
Re: (Score:3, Informative)
This is a story about Typescript being compiled (or translated if you prefer) into Go.
Go, in turn, is compiled into machine code like most compiled languages. You can read more about Go here [wikipedia.org]. It's a full featured programming language with its own interesting take on object oriented programming. It's strongly typed so, as you'd expect, normal JS would be inefficient if translated directly to Go, but TS at least reduces those inefficiencies.
Re:Previous implementation was JavaScript (Score:5, Informative)
I don't believe this is the case.
AFAICT it's just the TypeScript to JavaScript compiler that's being ported to Go.
this will allow it to compile TS projects faster (including for IDE analysis use), but shouldn't affect what happens at runtime of the user project. That is, the browser or node.js will still run js, but those .js files will have been produced by a native program that was written in Go (and then compiled)
Re: (Score:2)
Haven't had mod points in a couple of weeks or I'd mod you up +1 informative.
Re: (Score:2)
Microsoft missed the point (Score:2)
Microsoft needs to push for an ECMA/ANSI/W3C standard language to replace JavaScript; and TypeScript is not it.
Rewriting the TypeScript compiler in GO instead of continuing to use JavaScript for the compiler is an admission that JavaScript has fundamental limitations in speed, and more importantly maintainability for large code bases.
Suggestion:
1. Produce a reference implementation of a compiled language to run in browsers. Make this MIT licensed
2. Produce a reference implementation of a managed run time e
Microsoft replacing C/C++ (Score:2)
Part of a larger effort for Microsoft to rewrite / replace / remove any C/C++ code it has with an open source based language owned by another entity.
One would think C# would be used for the typescript compiler, but then Microsoft would be responsible for both the compiler and its underlying programming language.
Speculation: Microsoft will provide extension libraries for .net written in GO in a few years as the underlying cost of running .NET in Azure data centers versus native compiled code is in the tens o
Re: (Score:2)
as current typescript is written in typescript i would assume that the code to port is also strongly typed. either way, "typelessness" should have a negligble impact on efficiency (particularly performance wise, as is stated in tfa) in most situations, and since go doesn't support dynamic typing to begin with there is no way to compare.
then again javascript has been pretty efficient for a while, it should be performant enough for a compiler. they talk about js-go interoperation so they are not getting rid o
Re: (Score:2)
I had assumed this was a reimplementation of the TypeScript toolset (as you say). To me that's implicit when discussing the performance improvement of the tools. But yeah, that was an assumption on my part. I dunno if that also means the TypeScript toolchain will now generate Go. (I did see there's a "Go to JavaScript" translator, so maybe they'll offer Go as an alternative deployment.)
Re: (Score:2)
It's about the compiler toolchain being ported to Go.
Right now it's self-hosting (written in TypeScript).
This is very fucking slow.
Open source transpilers already exist that are much faster than tsc, but none of them completely re-implement all of tsc's features (like Intellisense)
The goal here is to make a version of tsc that has feature-parity with the self-hosted tsc, but performs like third-party native solutions.
Re: Next, porting English to French... (Score:1)
TypeScript to Go (Score:2)
with fries and a coke
Splintering (Score:3)
Re: (Score:2)
Making the typescript compiler faster by implementing it in go is ridiculous? Sure it's popular up self host compilers these days but when you're dealing with a language that is compiled to JavaScript, writing the compiler in a general purpose, compiled to native binary language is a reasonable thing to do. Gotta love the outage though.
Re: (Score:2)
tsc being self-hosting previously did not matter to you one bit, and a native implementation won't either, except that it will be faster to you.
Of course, since you didn't understand that, we can safely conclude that you're just trying to regurgitate words to sound smart, and none of this mattered to you at all, anyway.
Garbage in, garbage out. (Score:2)
It doesn't matter if it's slightly faster because if you start with garbage then you still end up with garbage.