Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
Programming Microsoft

Why Microsoft's Developers are Porting TypeScript to Go (infoworld.com) 49

Posted by EditorDavid from the on-the-Go dept.
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.
This discussion has been archived. No new comments can be posted.

Why Microsoft's Developers are Porting TypeScript to Go More

Why Microsoft's Developers are Porting TypeScript to Go

Comments Filter:

  • Previous implementation was JavaScript (Score:5, Interesting)

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

    • Re: (Score:2)

      by kriston ( 7886 )

      Came here to ask this.

      So, what's the runtime compiled to? Object code? Assembler?

      • Re: (Score:2, Informative)

        by karmawarrior ( 311177 )

        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)

          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)

          • Re: (Score:2)

            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

              • .Net byte code is jit compiled on the runtime.

                Or, you simply click in the IDE the checkbox [ ] AOT compilation.

                Simple, isn't it?

                Wow, after the Java haters now the .Net/C# haters pollute /. ?

                You could get an education mate, you know: information is at your fingertips.

                Gosh I hate stupid people.

                I go to the fridge now to get a beer.

                • Yes. Agree and know about the compiler to machine code flow along with other approaches like JVM, JIT, and ahead of time compilation to machine code.

          • AFAICT it's just the TypeScript to JavaScript compiler that's being ported to Go.

            What was the previous implementation?

            • Re: (Score:2)

              by _merlin ( 160982 )

              It was JavaScript. The whole thing started as JavaScript developers wanting JavaScript to suck less, so they made tools to compile a less shitty kind of JavaScript into regular JavaScript, writing those tools in JavaScript, because they are JavaScript developers.

              • Re: (Score:2)

                by narcc ( 412956 )

                They wanted JavaScript to be a completely different language because they didn't understand how to use dynamic languages effectively. This is the same ignorance that lead to ES6 breaking the language in fundamental ways.

                JavaScript, as it was early on, was a surprisingly elegant language. Some have called it "Lisp with C syntax" which isn't a bad description. Prototypal objects are not only simpler, they're far more powerful than their "classical" counterparts. Sure, it had some warts, like 'new', but th

                • You are half right.

                  But the problem with JS are the stupid implied type conversions and the lack of differencing between ints and doubles.

                  I do not know all the problems, but adding strings to each other when one is a number, trying to convert one string like "123" into a number first and so on: someone made a post about that 10 years ago on /.

                  The (auto-) conversion idiocy problems made me shudder.

                  The language itself, I always found cute. But I am one of those guys who prefers static typing over dynamic ... I

            • JavaScript or in the "eat your own dog food world": TypeScript, obviously.

        • Re: (Score:2)

          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.

    • JavaScript is in general Jit compiled.

      So, your guess is wrong.

      JavaScript has its limitations as it has no proper int and float/double types.

      Otherwise: it is as fast as C. Since - I am not sure - I would say: 20 years?

  • with fries and a coke

  • Splintering (Score:4, Insightful)

    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.

    • Re: (Score:2)

      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.

      • As I read it, it's not the compiler that is changed to Go, it's the whole typescript. But as I see it now, it's the underlying compiler which is being rewritten. But even then I think porting it to fab Go is ridiculous, why not just use a more established language.
    • 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'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.

      Short answer, if you write it in C#, only C# developers will maintain it and the job market and volunteer pool for C# is quite limiting, at best. Also, most don't want to install a CLR. Java is a far superior choice, but has the same issue. Even though it is much faster than Go, your users are stuck installing a JVM. Go is popular, for some reason unknown to me (unless your project was started before rust was created), and they said it was a good match for Typescript semantics.

      My first choice would

      • Re: (Score:1)

        by novitk ( 38381 )

        Short answer, if you write it in C#, only C# developers will maintain it and the job market and volunteer pool for C# is quite limiting, at best. Also, most don't want to install a CLR. Java is a far superior choice, but has the same issue. Even though it is much faster than Go, your users are stuck installing a JVM.

        Not sure on the developer count, I would think C# would not be substantially different from Go. Also with CLR, and to lesser extend with JVM, you don't need to install anything on target nowadays with ahead-of-time compilation. I do agree that the decision was clearly done with good PR in mind. All three languages mentioned (C#, Java and Rust) are far better candidates for the project on technical grounds.

      • Go and Rust try to compete with C/C++, so does Zick.
        Not with Java.

        The drawback of Java and C# is the start up time of the VM and the JIT compiling of the bytecode.
        The pros of both are bytecode morphers that add or instrument the loaded code before jitting.

        Rust looks like a pretty decent language to me, but I remember from my limited reading about go, I found it a bit awkward, too.

        Bottom line all those languages are all the same speed, with edge cases.

        The problem with a TypeScript compiler written in Typescr

        • Re: (Score:2)

          by Teckla ( 630646 )

          The drawback of Java and C# is the start up time of the VM and the JIT compiling of the bytecode.

          Both Java and C# can be AOT compiled.

          • Yes,
            which I clearly wrote in my post.

            Obviously, every language can be AOT compiled.

            Unless: you require features during runtime that get stripped by AOT compiling.

            And then again: that is obviously a design choice of the compiler makers.

  • It doesn't matter if it's slightly faster because if you start with garbage then you still end up with garbage.

  • christ on a pogo stick (Score:1)

    by Anonymous Coward

    The real news is, MSFT's previous attempt was 10x less efficient than it should have been. Also this pretty much ends the use of Typescript in web-based programs which was the whole reason it was made in the first place -- to make a less borked Javascript.

    If you're about to make a clean-sheet desktop program, and it's not utterly trivial, you're an idiot if you pick a language 10x less efficient than the alternatives. It's not like the alternatives were "win32 C" and "assembly language."

    Obviously if you're

  • The problems are clown-level "developers" (with apologies to actual clowns), no testing, no planning, no fixing of the massive mountain of tech-debt and general disrespect to the user that is seen as a product and a serf.

    Moving code to another language will do nothing.

  • ... is the current fad with the Web crowd. Many tools, stacks, compilers and APIs are being or have been ported to Rust and run as wicked fast native binares.

    fnm is a reimplementation of the Node Version Manager (nvm) in Rust, delivered as a binary program. Rolldown is a Rust implementation of the Rollup bundler.

    Tauri is a young and fresh alternative to Electron, working with a native foundation built in Rust as an alternative to Node, producing fast and small apps while taking web-centric cross-platform de

  • It's a language that they are already supporting.
    • Why not read any of the endless resources and interviews dealing with that exact question?

      They can port to Go in 6 months. A rewrite in Rust would've taken 3 years for no guaranteed improvement in speed.

Slashdot Top Deals

FORTRAN is for pipe stress freaks and crystallography weenies.

Close