Why Go?

[RyanCavanaugh]

Language choice is always a hot topic! We extensively evaluated many language options, both recently and in prior investigations. We also considered hybrid approaches where certain components could be written in a native language, while keeping core typechecking algorithms in JavaScript. We wrote multiple prototypes experimenting with different data representations in different languages, and did deep investigations into the approaches used by existing native TypeScript parsers like swc, oxc, and esbuild. To be clear, many languages would be suitable in a ground-up rewrite situation. Go did the best when considering multiple criteria that are particular to this situation, and it's worth explaining a few of them.

By far the most important aspect is that we need to keep the new codebase as compatible as possible, both in terms of semantics and in terms of code structure. We expect to maintain both codebases for quite some time going forward. Languages that allow for a structurally similar codebase offer a significant boon for anyone making code changes because we can easily port changes between the two codebases. In contrast, languages that require fundamental rethinking of memory management, mutation, data structuring, polymorphism, laziness, etc., might be a better fit for a ground-up rewrite, but we're undertaking this more as a port that maintains the existing behavior and critical optimizations we've built into the language. Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.

Go also offers excellent control of memory layout and allocation (both on an object and field level) without requiring that the entire codebase continually concern itself with memory management. While this implies a garbage collector, the downsides of a GC aren't particularly salient in our codebase. We don't have any strong latency constraints that would suffer from GC pauses/slowdowns. Batch compilations can effectively forego garbage collection entirely, since the process terminates at the end. In non-batch scenarios, most of our up-front allocations (ASTs, etc.) live for the entire life of the program, and we have strong domain information about when "logical" times to run the GC will be. Go's model therefore nets us a very big win in reducing codebase complexity, while paying very little actual runtime cost for garbage collection.

We also have an unusually large amount of graph processing, specifically traversing trees in both upward and downward walks involving polymorphic nodes. Go does an excellent job of making this ergonomic, especially in the context of needing to resemble the JavaScript version of the code.

Acknowledging some weak spots, Go's in-proc JS interop story is not as good as some of its alternatives. We have upcoming plans to mitigate this, and are committed to offering a performant and ergonomic JS API. We've been constrained in certain possible optimizations due to the current API model where consumers can access (or worse, modify) practically anything, and want to ensure that the new codebase keeps the door open for more freedom to change internal representations without having to worry about breaking all API users. Moving to a more intentional API design that also takes interop into account will let us move the ecosystem forward while still delivering these huge performance wins.

[EisenbergEffect]

I'd appreciate a much more in-depth write-up on this technical decision.

The choice of Go is quite surprising given that Microsoft makes C#, an obvious competitor to Go, which has bootstrapped its own compiler to great success. And of course, Microsoft has many customers that use both TS and C#. This seems like an unfortunate missed opportunity to unify Microsoft's web development story and do something greater. (In fact, this comes off as a bit of a vote of no confidence in C#, given that Anders is the original creator of C# and his team has now chosen not to use it. Seems that if there were issues with C#, the better move would be to work with the C# team to address those, making C# the best language for the new TS compiler. I'm just not sure how to interpret this move...)

If not C#, I would have expected Rust, since that's where the rest of the ecosystem is. So, another surprise there.

Additionally, both C# and Rust have strong support for WASM. In my understanding, much better than Go. A non-trivial set of folks need to run the TS compiler in-browser, so I'm not sure how this decision is going to affect those scenarios.

I'm glad performance is taking priority but confused (and a little disappointed) by the specifics.

Edit: See my follow-up post for my take on how this decision was likely made.

[kedare]

Also don't forget that .NET is much less portable than Go, using .NET would mean they would have to give up on *BSD for example.

Why perpetuate a lie? freshports.org/lang/dotnet

But yes, your reply demonstrates a larger problem faced by .NET - it is so unreasonably hated that choosing it, whenever it is the better product, comes with unsubstantiated criticism.

It's not because there is a package that it's supported or production ready :

FreeBSD is officially not supported as per the official documentation: https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md

dotnet/runtime#14537
dotnet/runtime#71338
and more issues if you search in the same repository, it's slowly getting better but I don't think it will be approved as official for quite some time for now.

Try to search a little bit next time.

I'm not a .NET hater I do use it and like it when it makes sense to use it (so not for this current usecase)

[3052]

If not C#, I would have expected Rust, since that's where the rest of the ecosystem is. So, another surprise there.

not really, Go is plenty popular. software development is not a monolith, so painting it that way is a weird take. one language (Rust) does not have to rule everything, nor does it. also you don't code in Rust or Go, so it seems off that you would even have a concern on this:

https://github.com/EisenbergEffect?tab=repositories

[Nugine]

Is it possible to extend static typescript and make tsc bootstrap itself?

1. write tsc in "static typescript"
2. compile tsc to wasm (using external compiler)
3. use tsc wasm to compile tsc

[with-heart]

Let's be honest. If the reasoning from @ahejlsberg is really focusing one-to-one mapping of the current base, Go would obviously not that close to the best candidate.

@FrankHB You're not familiar enough with either codebase to say that. The Go code follows a similar shape and structure to the original ts codebase, to the point that the Go implementation feels familiar to me despite not knowing Go at all.

[jeffpohlmeyer]

Yes, it seems the overriding goal was to have as close to a "copy/paste and fix" port as possible (maybe even something AI could do with high accuracy), to get to market as fast as possible. Performance, interoperability, unification of Microsoft's web development story, or any bigger picture vision, no matter how good, were never going to beat out that one deciding factor. I don't think maintainability or memory management really came into the choice either. C# does very well in that space. It really just came down to one thing.

This can’t be a surprise to anyone. “Inferior” products win out all the time. The iPhone and React are two examples that easily come to mind

[kkocdko]

Actually, I don't think tsc would make much use of Go's complex standard libraries like networking anyway.

Then maybe, tsc-go can be compiled using gccgo or tinygo(LLVM based). The WASM and other corner usage can still find a way.

[EisenbergEffect]

Using the TS compiler in-browser certainly isn't niche. Major industry tech is built assuming that capability.

[soypat]

TinyGo can provide significant speed boost in certain cases but can also be much slower when using the runtime (GC or threads) https://github.com/tinygo-org/tinybench

[PaluMacil]

@EisenbergEffect not being niche doesn't change the fact that Go can target wasm or wasi as output formats though. It's possible they could have to deal with a larger wasm binary in Go if the standard compiler is used instead of TinyGo, but it might have much better performance than a tsc in-browser experience which is probably worth it for most use cases

[Atulin]

Not beating the "Microsoft doesn't dogfood their own products" allegations

[ds300]

Excellent writeup. I'd also love to read more about the various prototypes/evaluations that went into picking go, it sounds like a fascinating journey. I'd be especially curious to hear about plans for the mitigation of go's wasm/js interop limitations. Also whether you expect to be able to leverage parallelism, or if maintaining a deep similarity between the go and TS codebases makes that difficult.

Incredibly excited for this!

[ds300]

in his announcement video Anders explains that yes they are using parallelism already.

[koakuma-chan]

Switch to Rust while it's not too late.

[panchengtao]

Would you consider a talk show

[PolpOnline]

Good luck building self-referential types in Rust, and any parallel stuff without making everything an Arc.

I like the ouroboros crate to build self-referential structs

[mattfbacon]

Good luck building self-referential types in Rust, and any parallel stuff without making everything an Arc.

That's literally exactly what Go does to share pointers. Rust just makes it explicit.

[thesaltygerman]

if Rust then have make hair dye to bright colors yes?

[xxshady]

i'm sorry for being 🤓🤓🤓
but here you got the answer: https://youtu.be/10qowKUW82U?t=13m19s

i'm pro-rust btw

[luka2220]

[Smrtnyk]

did you even read the intro post?

[luka2220]

Why else would I be asking for something more in depth?

[animitta]

It's time to give up on .NET. Even Microsoft has chosen Go for critical components like dapr framework and the TS compiler. Microsoft itself has abandoned its own product first.

[GenjiruSUchiwa]

It's time to give up on .NET. Even Microsoft has chosen Go for critical components like dapr framework and the TS compiler. Microsoft itself has abandoned its own product first.

.net is never can be a good option for develop any technology that'll run outside windows because it's designed and created for fundamentally windows, and it seems will never change. So microsoft being clever to not use .net unless simple things.

Tell me you don't what you are talking about without tell me you don't know what you are talking about.

[eqpoqpe]

"Whole infrastructure" has been seeing platform-agnostic development where Linux hosts are treated as often a primary target for 9 years already. I can see where you are coming from but the statements you make have not been true for almost a decade.

I'm trying to say .net's fundamentals are broken for other platforms and such as we saw in other languages(like in php, random function names, etc), fundamentals of a language don't change so easily in fact they don't significantly change most of the time. Even Microsoft uses Java on some of their software, which is direct replacement of c# / .net . So what we should say about that?

This is always your personal bias, contrary to reality, and you haven't even tried it yourself

[WwwZMing]

Frankly, Microsoft’s neglect of C# is obvious now. It’s not technical—they just don’t use it in their key products anymore. 🤔

[CosminSontu]

It's time to give up on .NET. Even Microsoft has chosen Go for critical components like dapr framework and the TS compiler. Microsoft itself has abandoned its own product first.

Don't use Dapr my friend, it is sub par in every aspect. Use Microsoft Orleans. Also, pair it with kubernetes.
FYI... There is another critical compiler out there called Roslyn which was build with C#.

[defunkydrummer]

Well, Microsoft implemented F#. If most of Microsoft software engineers had enough programming language fundamentals and paradigms experience, they would've used F# for almost all of their CLR-based codebase, and they would've evolved F# further, fixing the small things it lacks compared to OCaml/etc.

Since the reality is that they quickly abandoned F#, this gives you an idea of the kind of people Microsoft is having on their team. It is really hard to believe they start in the right direction (F#) and they quickly abandon one of their best projects.

[wubalubadubdub55]

Things like this make me ashamed to even build my career on C# .NET.

Microsoft doesn't use C# on any of their high impact, serious projects like Azure, Bing, Dapr, VS Code, Typescript etc. They overwhelmingly use tools outside of .NET ecosystem like Java, React, Go etc.

If they don't use their own tools in their flagship products, I have no confidence in their tools and it just signals the developer community that instead of focusing on learning, using and growing .NET, they should just focus their energy on learning Java, React, Go etc.

This attitude of Microsoft really hurts .NET community because for someone new to software development if they see Microsoft treating their own tools like second class citizens, they'll have no drive to learn .NET. And when more people do this over time, C# community will be pretty much gone.

Thanks Microsoft. I'll do my best to move my org away from C#/ Azure to Java, Go/ AWS etc.

Reference:

1. https://www.microsoft.com/openjdk
2. https://cdn.graph.office.net/prod/media/java/how-microsoft-applies-java.pdf
3. https://devblogs.microsoft.com/typescript/typescript-native-port/

[vinayvraman]

It'll be helpful to know from the author if .NET was considered and why C# was not preferred over Go for rewriting the TS compiler!

[eqpoqpe]

Things like this make me ashamed to even build my career on C# .NET.

Microsoft doesn't use C# on any of their high impact, serious projects like Azure, Bing, Dapr, VS Code, Typescript etc. They overwhelmingly use tools outside of .NET ecosystem like Java, React, Go etc.

If they don't use their own tools in their flagship products, I have no confidence in their tools and it just signals the developer community that instead of focusing on learning, using and growing .NET, they should just focus their energy on learning Java, React, Go etc.

This attitude of Microsoft really hurts .NET community because for someone new to software development if they see Microsoft treating their own tools like second class citizens, they'll have no drive to learn .NET. And when more people do this over time, C# community will be pretty much gone.

Thanks Microsoft. I'll do my best to move my org away from C#/ Azure to Java, Go/ AWS etc.

Reference:

1. https://www.microsoft.com/openjdk
2. https://cdn.graph.office.net/prod/media/java/how-microsoft-applies-java.pdf
3. https://devblogs.microsoft.com/typescript/typescript-native-port/

dotnet/csharplang isn't microsoft/csharplang 🥠

[antonius-ivan]

it's hurting C# developer. In Indonesia 95% Big Company use Go rather than C#. Because microsoft history over this. Than you wonder why Go Community have more people?

[eqpoqpe]

it's hurting C# developer. In Indonesia 95% Big Company use Go rather than C#. Because microsoft history over this. Than you wonder why Go Community have more people?

Bro just a TSC 😂, C# is still the best

[codythetaurus]

It'll be helpful to know from the author if .NET was considered and why C# was not preferred over Go for rewriting the TS compiler!

C# devs are crybabies. Its not a rewrite, its a port and Go was the best choice for this specific task after trying C#, Rust etc. If you dont respect their decision that produces 10x improve because of your personal attachment to C# thats a you problem. They didnt say C# or Rust are bad langs, they are just not the best choice in this task.

[mbektimirov]

Who is going to vibe-code it in a week?

[ghuntley]

The temptation is real. Currently, vibe coding my own compiler rn. IT IS POSSIBLE.

Embrace the cursed grammar of next...

fr vibe() int {  // main
    ngl i := 1
    ngl {
        lowkey i vibe 100 {  // i <= 100
            ngl output = ""
            
            lowkey i based 3 == 0 {  // i % 3 == 0
                output = output bussin "fr fr"  // "fr fr" = "Fizz"
            }
            
            lowkey i based 5 == 0 {  // i % 5 == 0
                output = output bussin "bussin"  // "bussin" = "Buzz"
            }
            
            lowkey output == "" {
                output = vibeIt(i)  // Convert int to string
            }
            
            vibe(output)  // Print the result
            i = i bussin 1
        } highkey {
            l  // break
        }
    }
    
    yeet 0
}

// Helper function to convert int to string
fr vibeIt(n int) string {
    ngl result = ""
    ngl temp = n
    
    lowkey temp == 0 {
        yeet "0"
    }
    
    ngl {
        lowkey temp highkey 0 {  // temp > 0
            ngl digit = temp based 10  // temp % 10
            result = string(digit bussin '0') bussin result
            temp = temp ratio 10  // temp / 10
        } highkey {
            l
        }
    }
    
    yeet result
} 

If anyone wants to do it - here's how... https://ghuntley.com/z80/ + https://ghuntley.com/stdlib

[JackySu]

lowkey im bussin vibing ngl no cap frfr yeeeeeeeeeeeeet

[elricmann]

What is missing from OP's statement is that there is still no technical justification to use Go.

> Go also offers excellent control of memory layout and allocation (both on an object and field level) without requiring that the entire codebase continually concern itself with memory management.

If the concern with migrating from a JavaScript runtime was avoiding manually managing memory then it's a weak argument since there have been many close comparisons of I/O-bound tasks between Node and Go that implied a minimal difference—which is relevant since the actual gains in using Go is only when there is a plausible use case for concurrency. For the record, there are many patterns in non-GC'd statically-typed compiled PLs e.g. pooled allocators that are barely challenging to use internally, i.e. in the case where there are upfront allocations.

> In non-batch scenarios, most of our up-front allocations (ASTs, etc.) live for the entire life of the program...

When the data is upfront, it is more reasonable to use allocation strategies that fit the task e.g. fixed-size or growable where it makes sense. It is also easier to cache and vectorize some procedures e.g. tokenization, but my assumption is that tsc is limited to any remotely reasonable performance delta that wouldn't necessarily scale but would be enough to feel fast so the average consumer does not complain.

Even when it is not feasible for a complete rewrite, it is more reasonable to use Rust/C++17^.

[SimonKocurek]

...If the concern with migrating from a JavaScript runtime was avoiding manually managing memory...

After listening to an interview with Anders Hejlsberg, my understanding is that the concern was keeping memory usage low, to make better use of CPU caches.

...the actual gains in using Go is only when there is a plausible use case for concurrency...

In the interview it was mentioned that they actually made use of the concurrency and got ~3x speedup (on top of the ~3x speedup by switching to a compiled language).

What is missing from OP's statement is that there is still no technical justification to use Go.

My subjective take on this is that it's better if teams have the freedom to choose the technology they want to work with, even if there is no perfect technical justification for it. 🙂

[CosminSontu]

That is the problem, they made a technical justification when it was mostly preference of Go vs C#.

[EduartePaiva]

That is the problem, they made a technical justification when it was mostly preference of Go vs C#.

Go syntaxe is closer to TypeScript. I Believe that's enough justification

[jirutka]

Go syntaxe is closer to TypeScript. I Believe that's enough justification

This is nonsense, just look at some examples of TS, Go, Rust and C# code. Go is a complete alien among them.

[Lattay]

have been many close comparisons of I/O-bound tasks

Heavily type checking compilers are CPU bound. Why do you think Rust is so slow?

[saint4eva]

Operating Systems (OS) that performed better than Linux and Windows were written in C# (Midori), and also one of the best compilers (Roslyn) in the industry is written in C#. So, I do not see the reason not to use C#, other than you were porting instead of rewriting. Well done to you and your team

[silencespeakstruth]

How and why Roslyn is "one of the best"?

[t-smirnov]

Can't wait when C# compiler will be rewritten in go!

[Aprite]

it is all business ;KPI win.

[AdditionAddict]

i too am butt hurt that a devtool that has nothing directly to do with C# hasn't been written in C#
this port that speeds up typescript at least 10x hurts me personally since it's not in C#

[sergiotapia]

If Microsoft doesn't use c# for their flagship products then why should engineers buy into a pretty closed ecosystem? It makes zero sense.

[AdditionAddict]

@sergiotapia i'll just link to the response #411 (reply in thread)

to reiterate, this was a port not a rewrite. they autogenerated code from their existing ts codebase and choose the best tool for this specific goal. 10x typescript does not hurt C# devs just as google using react doesn't hurt angular devs

[thesaltygerman]

no sense buy .NET it free

[matijagrcic]

I love the fact that while Rust might have been the "better" choice for a complete rewrite focusing solely on raw performance, TypeScript team prioritized a more pragmatic approach, opting for Go due to its similarity to the existing codebase, ease of use, and garbage collection support, facilitating a smoother and faster porting process.

Porting, Not Rewriting: The TS team weren't building from scratch. They needed to port the existing TypeScript codebase, preserving as much of the original structure and semantics as possible. This constraint heavily influenced the language choice.

Similarity to TS Code Style: The TS team felt Go's syntax and style were more closely aligned to the existing TypeScript compiler's codebase, which was described as more functional with data structures rather than a class based OOP. This means less time changing the code and patterns just to get it to work in the new language.

Garbage Collection (GC): The TypeScript compiler heavily relies on garbage collection. Go provides automatic memory management with a GC, simplifying the porting process compared to Rust, which would have required significant re-architecting to handle memory management manually.

Concurrency: Go offers good support for concurrency via goroutines and channels, which aligns well with the existing compiler's architecture and allows for easier parallel processing of files.

Ease of Use: The Go team recognized Rust has a steep learning curve. Go allows a wider range of developers to contribute and maintain the codebase more easily.

Rust's memory management model (borrow checker, lifetimes) would have required a complete rewrite and fundamental changes to the compiler's design.

Rust has a steeper learning curve, making finding developers more difficult.

[matijagrcic]

Boosting GH profile? Is that a thing? Only posted what I think, summarized. Never bet against Anders Hejlsberg and the whole Rust discussion is so boring, same happened when TS was announced, people claiming it looks like C# until they realized it doesn't after several years and now everyone is using it. C# is amazing, TS is amazing. And most of the people still doesn't understand that TS is powering all the IDEs, as without it we would still have notepad like tooling.

"The question isn't whether JavaScript is broken, but whether it's broken enough." ~ Anders Hejlsberg

If you know the history the initial bet was that JavaScript sucks and will go away which was the opposite of TypeScript approach.

[matijagrcic]

TBH Can't believe there's a discussion why the TS team went with GO and not C#. Like if someone knows C# that's Anders Hejlsberg.
Choosing Go was driven by engineering requirements of the TypeScript team.

On a related note, Mark Russinovich once highlighted the industry's broader move away from languages that pose security and reliability risks, stating:

"Speaking of languages, it's time to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required. For the sake of security and reliability. the industry should declare those languages as deprecated."

Different scenarios, but both underscore choosing languages strategically rather than based solely on familiarity or historical preference.

[cordasfilip]

Well before 'vibe' coding the goat Russinovich should try to release one thing on Windows 11 that isn't complete trash, it has gotten so terrible that windows is becoming unusable constantly crashing, updates that destroy your pc, and gigabytes of memory wasted on Spyware bloat. But I am sure c++ is the problem that search can't find ms teams when you type 'teams' rust fixing that for sure. Programming language is really the reason your software is bad.

[CosminSontu]

Similarity to TS Code Style

This is the strongest technical argument I've heard so far...

[codythetaurus]

Because this is what was said in this discussion post above and video explaining this. People are leading with their emotions to a lang, are mad and clearly didnt read, here's one of the quotes "Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable."

[HotCakeX]

[FACorreiaa]

Why do you care if in the end you will still be using TS ? The language under the hood is still garbage hiding fake type safety, you just have faster tooling now.

[FACorreiaa]

Yeah. Microsoft devs using Go for their internal tools.. on their mac's... hum.

[carlos-menezes]

At the end of the day, the focus is on boosting performance and enhancing the DX across codebases, even if some community members might have preferred Rust or another language. It’s a reminder that the right tool for the job is often the one that offers the best overall trade-offs for the project’s needs and the team's expertise.

I trust these people to make informed decisions and support them going forward with the rewrite in Go despite not being a fan of Go at all and much preferring Rust. To me, it doesn't make a difference if it's built in Go, Rust, C++, F#, Brainfuck or ADA: at the close of play, I still get the benefits of faster TypeScript tooling regardless of the hidden intrincacies.

[CodeAngry]

This choice would've surprised me too... more than a decade ago. But I already depleted my surprise a long time ago, seeing a Microsoft Build and watching in shock as all Microsoft developers used Macs on stage while doing their presentations about the Microsoft developer languages and ecosystem. Since then I personally have little expectations... A win for programming diversity! Why use your own tools when you can create unneeded external dependencies?

[Winfle]

Why it is important for you?
It is just a layer that generates js. It was written in JS and nobody complained why not C#

[2mikeg]

Let's write Go in Rust ahahha

[tonyqus]

Perhaps rewrite C# compiler with Go

[JackySu]

language choice is just a smoke bomb concealing their reluctance to refactoring the codebase, and yeah, I feel you C# users.

[muaaz9329]

I am pretty sure whichever language they had used under the hood would have butt hurt the community's feelings as always, but it's a big win for Go lang

[TimothyMeadows]

This is a huge loss for C#, the differences are so laughably small for a language you can CONTROL vrs one you can't. The optics of this are tragic. This was not a smart choice and will have repercussions much greater than typescript. This was a mistake.

[KRTirtho]

Tbh, there's always going to be more Go devs than C#/.NET devs.
Also, it's far easier to get started with go, and you can literally learn it in a week. Which means it has the upside of more contributions. It has a really fast compile time, supports WASM* & is popular.
Also, as far as I C# compiles to bytecode to be executed by dotnet common language runtime. This is the norm in that ecosystem.
AOT compilation is not that common. But Go always compiles, it perfected its compilation strategy over the years. Go results in a marginally smaller binary than C# AOT binary. So less bandwidth usage in npm which is owned by Microsoft. In the end,

• Go is popular
• Easier and opens more contributions
• More platform support
• Fast compilation & Smaller binary size
• Reduces bandwidth

C# denies all those points. I don't know how C# would've been a better choice

[alexaka1]

The you can learn the language in a week and then go and work on one of the most complex projects on GitHub justification is not something I will understand for a while.

[ahejlsberg]

(Adding my comment again since the original one was a reply to a reply and gets swallowed by thread truncation...)

Our decision to port to Go underscores our commitment to pragmatic engineering choices. Our focus was on achieving the best possible result regardless of the language used. At Microsoft, we leverage multiple programming languages including C#, Go, Java, Rust, C++, TypeScript, and others, each chosen carefully based on technical suitability and team productivity. In fact, C# still happens to be the most popular language internally, by far.

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, providing excellent ergonomics for tree traversal, ease of memory allocation, and a code structure that closely mirrors the existing compiler, enabling easier maintenance and compatibility.

In a green field, this would have been a totally different conversation. But this was not a green field - it's a port of an existing codebase with 100 man-years of investment. Yes, we could have redesigned the compiler in C# from scratch, and it would have worked. In fact, C#'s own compiler, Roslyn, is written in C# and bootstraps itself. But this wasn't a compiler redesign, and the TypeScript to Go move was far more automatable and more one-to-one in its mapping. Our existing codebase is all functions and data structures - no classes. Idiomatic Go looked just like our existing codebase so the port was greatly simplified.

While this decision was well-suited to TypeScript’s specific situation, it does not diminish our deep and ongoing investment in C# and .NET. A majority of Microsoft's services and products rely heavily on C# and .NET due to their unmatched productivity, robust ecosystem, and strong scalability. C# excels in scenarios demanding rapid, maintainable, and scalable development, powering critical systems and numerous internal and external Microsoft solutions. Modern, cross-platform .NET also offers outstanding performance, making it ideal for building cloud services that run seamlessly on any operating system and across multiple cloud providers. Recent performance improvements in .NET 9 further demonstrate our ongoing investment in this powerful ecosystem (https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/).

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!

No single language is perfect for every task, and at Microsoft, we celebrate the strength that comes from diversity in programming languages. Our commitment to C# and .NET remains stronger than ever, continually enhancing these technologies to provide developers with the tools they need to succeed now and into the future.

[Winfle]

Thank you for the valuable clarifiction!

[ForkBug]

There may be a logical mistake in the response:

1. The second and third paragraph say Go was chosen due to development speed on the existing codebase.

2. The fourth paragraph says C# is good. And the runtime performance is good.

3. The fifth paragraph says some words, and then says"10x outcome!". We know that '10x' comes from the comparison of the Go compiler vs. the TypeScript compiler, not C#.

The response explains why C# wasn't chosen but still says '10x outcome!'

I'm not a native English speaker. Is this a conventional expression in the English-speaking world, a logical mistake, or something else?

[HotCakeX]

I was wondering if you could do something like what the Edge team did with Chromium.

Chromium wasn't perfect, had lots of unneeded features and was also missing lots of features the Edge team required. So, what they did was they made lots of important contributions to the Chromium source code that ultimately benefited not only the Edge users but also any other browser on Windows that uses Chromium engine.

So why couldn't the same thing be applied here? What if you selected C#/.NET, formed a special internal team that would focus on bringing any missing features to the C#/.NET or improve it so that it would meet your requirements and also benefit all of the C#/.NET developers. You'd have even more control over the compiler than Go because it would be the repository that Microsoft controls.

[ismoil793]

How does TypeScript currently work in my local React (Next.js/Vite) setup?

• As I understand it, when I install TypeScript via NPM (npm install typescript), it runs on Node.js (V8, C++) and executes tsc, which is itself written in TypeScript. Is this correct?

What changes for developers using TypeScript locally?

• If parts of TypeScript move to Go, will npm install typescript still install the same JavaScript-based compiler (tsc) by default?
  Will there be a separate Go-based compiler (tsc-go or something similar), or will it gradually replace the existing one?

Will TypeScript still depend on Node.js and V8?

• Currently, TypeScript runs on Node.js (which runs on V8, written in C++). After the Go migration, will tsc still depend on Node.js, or is the plan to remove that dependency over time?

[runny-yolk]

I suppose I shouldn't be surprised that well-reasoned post that more-or-less boils down to "you'd understand if you worked on the project" has a lot of angry opinions from people who do not work on the project. I think it's a testament to how much Microsoft's culture has improved over the last decade that the developers on one of their biggest projects are able to pick the tool they think is the best fit for the job, instead of being forced to pick the Microsoft tool because it's the Microsoft tool.

[vincywindy]

臣等正欲死战，陛下何故先降？

[Louis-Bon]

Opinions and debates on language is what devs do the best.
Lets appreciate the effort from the TS team and enjoy a huge performance boost.
Thanks a lot for this btw !

[mrablfz05]

I was learning Rustlang:/ the next step will be Golang:)

[arslivinski]

I like the pragmatism of choosing Go. It's not a rewrite, it's a port. The thing that I don't like in Go is that (I've read this a few years ago, so this might not be the current reality) was created by some folks that also created Unix, Inferno, and Plan9, so the whole part that interact with the OS (file system, time, ...) is very Unixy and don't play well on Windows.

[RyanCavanaugh]

I'm going to lock this (for a while) as comments are getting a bit circular, the most salient points have been addressed, and there are a lot of incoming links to this page that aren't loading correctly for folks because the thread is too long. We really appreciate the input and hope that we've provided clarity on this one.