alt Hacker NewsI suppose my comment sort of implies this. I think the naive knee jerk reaction is that if you can spit out perfect machine level code against a specification, then logically being closer to bare metal would help with performance. However, without knowing the details of how things worked it is tough to say whether it is truly "reasonable" or not.
But more importantly, the Typescript team themselves [1] picked Golang mostly out of ergonomics and ease of porting at the time. It is becoming more increasingly more to "taste" what ergonomics means. Notably, they did not pick it because they believed it to be the fastest option. But speed was on the mind, giving way to ergonomics and ease of porting. At least, this is my read.
[1] https://github.com/microsoft/typescript-go/discussions/411
Replies
The author of esbuild used Rust and later switched to Go. He describes some of his experience here:
https://news.ycombinator.com/item?id=22336284
It is one person and one project, but I found it interesting to read about his experience.
I like Go, but I probably would have tried Rust first because I want pattern matching when implementing languages.
The notable thing that these LLM-generated ports aren't doing is _rewriting in Go_. TypeScript 7 is a lot faster than the JS/TS-based version 6, but memory use is a major bottleneck.
However, it mostly represents a mechanical port of the old codebase to Go. What I haven't seen anyone do is try a true rewrite in Go optimized for performance (whilst keeping a strong emphasis on readability).
> then logically being closer to bare metal would help with performance
Once you move beyond interpreters, performance is mostly a property of how much effort you want to put into profiling and optimization, not any specific properties of a programming language (YMMV of course).