CARVIEW |
Navigation Menu
-
Notifications
You must be signed in to change notification settings - Fork 716
Why Go? #411
Replies: 112 comments · 268 replies
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 466 -
π 238 -
π 11 -
π 1 -
β€οΈ 12 -
π 14 -
π 25
-
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 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) |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 9 -
π 2
-
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: |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
-
Is it possible to extend static typescript and make
|
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
@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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
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 |
Beta Was this translation helpful? Give feedback.
All reactions
This comment was marked as off-topic.
This comment was marked as off-topic.
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
β€οΈ 11
-
Using the TS compiler in-browser certainly isn't niche. Major industry tech is built assuming that capability. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 31 -
π 1
-
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 |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 8
-
@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 |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 3
-
Not beating the "Microsoft doesn't dogfood their own products" allegations |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 3 -
π 2 -
π 134
-
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! |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 7 -
π 4
-
in his announcement video Anders explains that yes they are using parallelism already. |
Beta Was this translation helpful? Give feedback.
All reactions
-
Switch to Rust while it's not too late. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 58 -
π 278 -
π 56 -
π 6 -
π 16 -
π 3
-
Would you consider a talk show |
Beta Was this translation helpful? Give feedback.
All reactions
-
I like the |
Beta Was this translation helpful? Give feedback.
All reactions
-
That's literally exactly what Go does to share pointers. Rust just makes it explicit. |
Beta Was this translation helpful? Give feedback.
All reactions
-
if Rust then have make hair dye to bright colors yes? |
Beta Was this translation helpful? Give feedback.
All reactions
-
i'm sorry for being π€π€π€
|
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
-
Beta Was this translation helpful? Give feedback.
All reactions
-
π 8
-
did you even read the intro post? |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 24 -
π 2
-
Why else would I be asking for something more in depth? |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 87 -
π 53 -
π 12 -
π 2
-
Tell me you don't what you are talking about without tell me you don't know what you are talking about. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 13
-
This is always your personal bias, contrary to reality, and you haven't even tried it yourself |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 7
-
Frankly, Microsoftβs neglect of C# is obvious now. Itβs not technicalβthey just donβt use it in their key products anymore. π€ |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 6 -
π 5
-
Don't use Dapr my friend, it is sub par in every aspect. Use Microsoft Orleans. Also, pair it with kubernetes. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
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: |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 101 -
π 46 -
π 35 -
π 4 -
β€οΈ 1
-
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! |
Beta Was this translation helpful? Give feedback.
All reactions
-
dotnet/csharplang isn't microsoft/csharplang π₯ |
Beta Was this translation helpful? Give feedback.
All reactions
-
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? |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
Bro just a TSC π, C# is still the best |
Beta Was this translation helpful? Give feedback.
All reactions
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 12 -
π 7
-
Who is going to vibe-code it in a week? |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 7 -
π 32
-
The temptation is real. Currently, vibe coding my own compiler rn. IT IS POSSIBLE. Embrace the cursed grammar of next...
If anyone wants to do it - here's how... https://ghuntley.com/z80/ + https://ghuntley.com/stdlib |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
-
lowkey im bussin vibing ngl no cap frfr yeeeeeeeeeeeeet |
Beta Was this translation helpful? Give feedback.
All reactions
-
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 Even when it is not feasible for a complete rewrite, it is more reasonable to use Rust/C++17^. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 22 -
π 30 -
π 1
-
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.
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).
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. π |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 18 -
π 2
-
That is the problem, they made a technical justification when it was mostly preference of Go vs C#. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2 -
π 2
-
Go syntaxe is closer to TypeScript. I Believe that's enough justification |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2 -
π 1
-
This is nonsense, just look at some examples of TS, Go, Rust and C# code. Go is a complete alien among them. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
-
Heavily type checking compilers are CPU bound. Why do you think Rust is so slow? |
Beta Was this translation helpful? Give feedback.
All reactions
-
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 |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1 -
π 4 -
π 8 -
π 5
-
How and why Roslyn is "one of the best"? |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
-
Can't wait when C# compiler will be rewritten in go! |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 181
-
it is all business ;KPI win. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
-
i too am butt hurt that a devtool that has nothing directly to do with C# hasn't been written in C# |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 68 -
π 14 -
π 97 -
β€οΈ 1
-
If Microsoft doesn't use c# for their flagship products then why should engineers buy into a pretty closed ecosystem? It makes zero sense. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 5 -
π 5
-
@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 |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
no sense buy .NET it free |
Beta Was this translation helpful? Give feedback.
All reactions
-
Beta Was this translation helpful? Give feedback.
All reactions
-
π 54 -
π 114 -
π 6 -
π 7 -
β€οΈ 10
-
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.
If you know the history the initial bet was that JavaScript sucks and will go away which was the opposite of TypeScript approach. |
Beta Was this translation helpful? Give feedback.
All reactions
-
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. On a related note, Mark Russinovich once highlighted the industry's broader move away from languages that pose security and reliability risks, stating:
Different scenarios, but both underscore choosing languages strategically rather than based solely on familiarity or historical preference. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1 -
π 1
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 4
-
This is the strongest technical argument I've heard so far... |
Beta Was this translation helpful? Give feedback.
All reactions
-
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." |
Beta Was this translation helpful? Give feedback.
All reactions
-
Beta Was this translation helpful? Give feedback.
All reactions
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2 -
π 3
-
Yeah. Microsoft devs using Go for their internal tools.. on their mac's... hum. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
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? |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1 -
π 1 -
π 1
-
Why it is important for you? |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
-
Let's write Go in Rust ahahha |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
Perhaps rewrite C# compiler with Go |
Beta Was this translation helpful? Give feedback.
All reactions
-
language choice is just a smoke bomb concealing their reluctance to refactoring the codebase, and yeah, I feel you C# users. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1 -
π 1
-
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 |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1 -
π 4
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2 -
π 3
-
Tbh, there's always going to be more Go devs than C#/.NET devs.
C# denies all those points. I don't know how C# would've been a better choice |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
(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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
β€οΈ 24
-
Thank you for the valuable clarifiction! |
Beta Was this translation helpful? Give feedback.
All reactions
-
There may be a logical mistake in the response:
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? |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
How does TypeScript currently work in my local React (Next.js/Vite) setup?
What changes for developers using TypeScript locally?
Will TypeScript still depend on Node.js and V8?
|
Beta Was this translation helpful? Give feedback.
All reactions
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 3 -
β€οΈ 4
-
θ£ηζ£ζ¬²ζ»ζοΌιδΈδ½ζ ε ιοΌ |
Beta Was this translation helpful? Give feedback.
All reactions
-
Opinions and debates on language is what devs do the best. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
I was learning Rustlang:/ the next step will be Golang:) |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
-
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. |
Beta Was this translation helpful? Give feedback.
All reactions
-
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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions