Why Go? (opens in new tab)

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

I guess this sheds a bit of light in to the why not rust debate.

The key takeaways for me:

> many languages would be suitable in a ground-up rewrite situation.

> 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

> 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

My initial thought was "why not Rust" and those passages do a pretty good job of answering the question, IMO.

I don't know why some people are losing their minds over it being in go... ok, so I kinda expected rust because that's what all the cool kids are doing - rewriting in rust - but I think go is a pretty good choice for a domain like this.

It's hard to tell which camp is more angry: the C# developers stating Microsoft is ditching its own ecosystem or the Rust developers unwilling to accept anything in this category not being written in Rust.

From my understanding, all three options (Go, C#, and Rust) represent a significant speedup. The only legitimate concern I see is the one around WASM support, which is quite valid.

But at the end of the day, it seems like the team is making a decision that maximizes speed and deliverability, with the offset being that some cracks are now present (e.g. WASM). I can respect them for that choice.

(OP author here) Lots of people reading too much into the tea leaves here; this is just a matter of picking the best tool for this particular task, and our task (porting a JS codebase to the fastest available native target that still works in terms of not altering program structure as part of the port) is pretty unusual as far as things go

I would also recommend reading kdy1's observations when faced with the same task: https://kdy1.dev/2022-1-26-porting-tsc-to-go . The only caveat I'd add is that I can't tell where the 62x measurement in that post came from. Our own experiments doing Rust and Go implementations showed them within the margin of error, with certain phases being faster in one vs the other.

I have written a lot of code in many languages, but most recently in Go and Rust. I had actually considered myself a Rust convert up until recently, and if you look at my comment history, you will find me calling out Go for being a poorly designed language on multiple occasions.

I have changed my mind.

Why? Well, I started writing Go again, so I had experience writing both Rust and Go within a close timeframe to each other. These are very different languages with very different strengths. I think choosing one over the other largely comes down to what you are writing. For deep, complex typed algo code esp. things that need to be very fast, I would likely still choose Rust, but Go really excels at writing infra code. Code that needs to be fast, but more importantly needs to be iterated quickly, and Go compiles MUCH faster than Rust.

Most of my objections to Go I find in the "programming language theory part of my brain". I am a language designer at heart, and by that, I mean I iterate on language designs and have a deep love for PLT. The issue I have found is that, while Rust is awesome in theory (and still one of my favorite languages), actually building things quickly is more satisfying to me, and I am finding I can build in Go about 2x the rate as in Rust. I didn't think this was the case until I actually started tracking my own iteration speed. Things like compile time DO matter, because you are always compiling at some level, even if just running tests. Also, every language feature is just a tiny bit of friction, and Go is so simple that friction is nearly non-existent.

Most of my Go language objectionss, such as nil pointers, lack of enums, multi return vs tuples are much less an issue in practice than they are in theory, and once you sit down and actually think on 'why' Go might have done what it did, it actually makes some sense. I had a few lightbulb moments I could expand on in a different post.

In summary, Go and Rust are very different languages. I really like both, but in different use cases. I am back to writing more Go than Rust, but I expect to write some of both going forward.

Maybe a stupid question but...

With typescript 7 written in Go, am I able to download typescript 7 as an npm module in my package and use that? No, right? I have to have it installed on my system and maybe have a version manager to use different versions across projects. Or maybe it can be compiled to WA and published to npm?

Why not Rust? https://youtu.be/10qowKUW82U?t=769

Why not C#? https://youtu.be/10qowKUW82U?t=1155

Seeing all the comments about Rust in that other discussion was kind of disappointing. I have a feeling if they chose Rust, go fans wouldn't be complaining about it not being written in Go.

I think if you looked at the typescript code base you’d understand.

It’s a mess!!!

As most functional projects are. There’s just data structures and code and good luck finding anything or trying to figure out why something is where it is.

Seriously go look at the code. It’s not like c#.

Makes no sense, when there is C#.

This is posted in the context of the discussion ongoing at https://news.ycombinator.com/item?id=43332830, elsewhere on the front page as I write this.

Note if you are a title-only-before-commenting reader that this is not a generalized apologia for Go, but specifically for the case of porting the Typescript compiler, so reciting the Litany Against Go in a general sense is not really on topic.

(The Litany, naturally, is:

    I must not Go.
    Go is the mind-killer.
    Go is the little-death that brings total obliteration.
    I will face Go.
    I will permit it to pass over me and Go through me.
    And when it has gone past, I will turn the inner eye 
    to see its path.
    Where the Go has Go'ed there will be nothing.
    Only I will remain.

)

For everyone asking Why Not C#? I think it's fair, given Anders who designed both C# and TypeScript was the one who announced this on X and is involved, to take them at face value on things such as "Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable." Maybe after doing a bunch of prototypes, like they said they did, it was just the obvious choice at the level of the code itself, and I think if that's where they focused their decision rubric instead of on other factors like NIH or the current hot thing it's a refreshing way of making a decision.

It's not widely known, but the 90s rock band Pearl Jam answered this very question [1].

[1] https://www.youtube.com/watch?v=kzJu4r5vvo8

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

From this I can understand why they did not go with, say, Rust - but there are other compiled languages with garbage collection that could have worked well. Why Go over Crystal? I imagine it's that the Go is the most mature ecostystem (i.e. the interop) but it feels like a missed opportunity.

If people want this to be in <insert their flavour of the month language here> they should do it themselves rather than complaining.

Why not rust? It only takes 5 years to compile the codebase. So much time for activities!

Great work, did you consider Java+GraalVM?