Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Programming Microsoft

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.

Why Microsoft's Developers are Porting TypeScript to Go

Comments Filter:
  • by david.emery ( 127135 ) on Saturday March 15, 2025 @12:08PM (#65235825)

    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...)

    • by kriston ( 7886 )

      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.

        • by rta ( 559125 ) on Saturday March 15, 2025 @12:41PM (#65235879)

          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)

          • by caseih ( 160668 )

            Haven't had mod points in a couple of weeks or I'd mod you up +1 informative.

          • You are completely correct.
          • 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

            • 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

        • by znrt ( 2424692 )

          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

        • Negative.
          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.
  • with fries and a coke

  • by SuperDre ( 982372 ) on Saturday March 15, 2025 @01:25PM (#65235969) Homepage
    It's so ridiculous what MS does, why not port everything to C# having one language in everything so it'll be easier to optimize compilers even more. They have Blazor now for webdevelopment and that's great. Now 'we' have to learn yet another language which really doesn't add anything to the mix other then another developer's favorite flavor of syntax.
    • by caseih ( 160668 )

      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.

    • You don't have to learn anything.
      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.
  • It doesn't matter if it's slightly faster because if you start with garbage then you still end up with garbage.

Real Programs don't use shared text. Otherwise, how can they use functions for scratch space after they are finished calling them?

Working...