I don't think this is accurate.

Javascript is not slow because of GC or JIT (the JVM is about twice as fast in benchmarks; Go has a GC) but because JS as a language is not designed for performance. Despite all the work that V8 does it cannot perform enough analysis to recover desirable performance. The simplest example to explain is the lack of machine numbers (e.g. ints). JS doesn't have any representation for this so V8 does a lot of work to try to figure out when a number can be represented as an int, but it won't catch all cases.

As for "working solution over language politics" you are entirely pulling that out of thin air. It's not supported by the article in any way. There is discussion at https://github.com/microsoft/typescript-go/discussions/411 that mentions different points.

I think JS can really zoom if you let it. Hamsters.js, GPU.js, taichi.js, ndarray, arquero, S.js, are all solid foundations for doing things really efficiently. Sure, not 'native' performance or on the compile side, but having their computational models in mind can really let you work around the language's limitations.

JS can be pretty fast if you let it, but the problem is the fastest path is extremely unergonomic. If you always take the fastest possible path you end up more or less writing asm.js by hand, or a worse version of C that doesn't even have proper structs.

I find these userland libraries particularly effective, because you'll never leave JS land, conveniently abstracting over Workers, WebGL/WebGPU and WASM.

JS, interestingly, has a notion of integers, but only in the form of integer arrays, like Int16Array.

I wonder if Typescript could introduce integer type(s) that a direct TS -> native code compiler (JIT or AOT) could use. Since TS becomes valid JS if all type annotations are removed, such numbers would just become normal JS numbers from the POV of a JS runtime which does not understand TS.

AssemblyScript (for WASM) and Huawei's ArkTS (for mobile apps) already exist in this landscape. However, they are too specific in their use cases and have never gained public attention.

you replied to an LLM generated comment. if you look at the posting history you can confirm it

> is this the beginning of a larger trend where JS/TS tooling migrates to native implementations

No, it is not. It is a continuation of an existing trend

You may be interested in esbuild (https://github.com/evanw/esbuild), turborepo (https://github.com/vercel/turborepo), biome-js (https://github.com/biomejs/biome) are all native reimplementations of existing projects in JS/TS. esbuild is written in Go, the others in Rust.

> reveals something deeper: Microsoft prioritized shipping a working solution over language politics

Its not that "deep". I don't see the politics either way, there are clearly successful projects using both Go and Rust. The only people who see "politics" are those who see people disagreeing, are unable to understand the substance of the disagreement and decide "ah, it's just politics".

This is not accusatory, but do you write your comments with AI? I checked your profile and someone else had the same question a few days ago. It's the persistent structure of "it isn't X – it's Y" with the em dash (– not -) that makes me wonder this. Nothing to add to your comment otherwise, sorry.

Sorry for being pedantic but they are using an en dash (–) not an em dash (—) which is a little strange because the latter is usually the one meant for adding information in secondary sentences—like commas and and parentheses. In addition, in most styles, you're not supposed to add spaces around it.

So, I don't think the comment is AI-generated for this reason.

"The en-dash is also increasingly used to replace the long dash ('—', also called an em dash or em rule). When using it to replace a long dash, spaces are needed either side of it – like so." https://en.wikipedia.org/wiki/En_(typography)

You're right, oops. I agree with your reasoning (comment still gives off slop vibes but that's unprovable). But the parent has been flagged, so I'm not sure if that means admins/dang has agreed with me or if it was flagged for another reason.

I think anyone can flag a comment, and if enough people flag a comment, it will become flagged.

em-dash is shift-option-hyphen on macOS, so it's not a good heuristic—I use it myself.

They're using en-dash which is even easier: option-hyphen.

This is the wrong way to do AI detection. For one, LLM would have used the right dash. But at least find someone wasting our time with belabored or overwrought text that doesn't even interact with anything.

This is definitely AI, repetitive and reads in style of a marketing copy / sensational report.

They're not "definitely" an AI. Sounds like a normal Go enthusiast to me.

A Go enthusiast who’s never heard of esbuild? Not impossible, but unlikely.

So, a go enthusiast who does exclusively backend work? Seems likely enough, given that community's overall disdain for Javascript.

You know, some humans use the correct dash too...

The em dash thing is not very conclusive. I have been writing with the em dash for many years, because it looks better and is very accessible on Mac OS (long press on dash key), while carrying a different tone than the simple dash. That, and I read some Tristram Shandy.

Two hyphens (-) make a em dash (—) on Apple devices and many word processors.

In the pre-Unicode days, people would use two hyphens (--) to simulate em dashes.

That would explain a lot.

> The Go choice over Rust/C# reveals something deeper: Microsoft prioritized shipping a working solution over language politics. Go's simplicity (compared to Rust) and deployment model (compared to C#) won the day.

I'm not sure that this is particularly accurate for the Rust case. The goal of this project was to perform a 1:1 port from TypeScript to a faster language. The existing codebase assumes a garbage collector so Rust is not really a realistic option here. I would bet they picked GCed languages only.

Also explained in the FAQ: https://github.com/microsoft/typescript-go/discussions/411

I can't imagine the devs at Microsoft have any issues with C#'s "deployment model."

I can imagine C# being annoying to integrate into some CIs, for instance. Go fits a sweet spot, with its fast compiler and usually limited number of external dependencies.

I assume they picked Go because the binaries can be very stand alone.

I don't see why Go deployment model is superior to C#. You can easily build native binaries in C# as well nowadays.

I get the impression that, because Go has a lot of similar semantics to Typescript, it was easier to port to Go than other languages.

From https://github.com/microsoft/typescript-go/discussions/411

> Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.

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

Personally, I'm a big believer in choosing the right language for the job. C# is a great language, and often is "good enough" for many jobs. (I've done it for 20 years.) That doesn't mean it's always the best choice for the job. Likewise, sometimes picking a "familiar language" for a target audience is better than picking a personal favorite.

Smaller binary sizes for easier + cheaper distribution might be a factor.

You can make very small binaries in C# if you want to.

But, the team posted their rationale for Go here: https://github.com/microsoft/typescript-go/discussions/411

Come on… 1 statically linked executable and it can cross build incredibly easily. There's no comparison even.

> When a language team abandons self-hosting (TS in TS) for raw performance (Go), it signals we've hit fundamental limits in JS/TS for systems programming.

I hope you really mean for "userspace tools / programs" which is what these dev-tools are, and not in the area of device drivers, since that is where "systems programming" is more relevant.

I don't know why one would choose JS or TS for "systems programming", but I'm assuming you're talking about user-space programs.

But really, those who know the difference between a compiled language and a VM-based language know the obvious fundamental performance limitations of developer tools written in VM-based languages like JS or TS and would avoid them as they are not designed for this use case.

Back in my day, writing compilers was part of systems programming.

Yeah, the term has changed meaning several times. Early on, "systems programmer" meant basically what we call a "developer" now (by opposition to a programmer or a researcher).

At that time, what would have been the distinction between "programmer" and "developer"?

If my memory serves, the "programmer" was essentially a mathematician, working on a single algorithm, while a "system developer" was building an entire system around it.

It *almost* sounds like you're telling the authors, one of which posted this, what their motivations are.

>The Go choice over Rust/C# reveals something deeper: Microsoft prioritized shipping a working solution over language politics. Go's simplicity (compared to Rust) and deployment model (compared to C#) won the day. Even Anders Hejlsberg – father of C# – chose Go for pragmatic reasons!

I don't follow. If they had picked Rust over Go why couldn't you also argue that they are prioritising shipping a working solution over language politics. It seems like a meaningless statement.

Go with parametric types is already a reasonably expressive language. Much more expressive than C in which a number of compilers has been written, at least initially; not everyone had the luxury of using OCaml or Haskell.

There is already a growing number of native-code tools of the JS/TS ecosystem, like esbuild or swc.

Maybe we should expect attempts of native AOT compilation for TS itself, to run on the server side, much like C# has an AOC native-code compiler.

I wish there was a language like rust without the borrow checking and lifetimes that was also popular and lives in the same area as go. Because I think go is actually the best language in this category but it’s only the best because there is nothing else. All in all golang is not an elegant language.

O'Caml is similar, now that it has multicore. Scala is also similar, though the native code side (https://scala-native.org/en/stable/) is not nearly as well developed as the JVM side.

The problem with O'Caml is it won't get popular because people are afraid of FP. But I would be totally down to use it.

Rust loses a lot of its nice properties without borrow checking and lifetimes, though. For example, resources no longer get cleaned up automatically, and the compiler no longer protects you against data races. Which in turn makes the entire language memory unsafe.

I believe OP meant to give it a GC like in Go, while keeping other features from Rust from enums/match/generics/traits/etc etc.

This should prevent most of the memory safety issues, though data races could still be tricky (e.g. Go is memory unsafe due to data races)

OTOH it would still have Rust's sane type system and all the nice features it makes possible.

OCaml and Haskell already have that nice type system (and even more nice). If OCaml's syntax bothers you, there is Reason [1] which is a different frontend to the same compiler suite.

Also in this space is Gleam [2] which targets Erlang / OTP, if high concurrency and fault tolerance is your cup of tea.

[1]: https://reasonml.github.io/

[2]: https://gleam.run/

It’s not popular compared to Go/Rust, but many find Nim scratches that itch:

https://nim-lang.org/

Zig is another popular neo-language in the same rough space.

That language is Rust, though.

> Go's simplicity

I think they went for Go mostly because of memory management, async and syntactic similarity to interpreted languages which makes total sense for a port.