Hacker News Reader

Comment by vaughands | Hacker News Reader

I 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

View on HN

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.

Very interesting. With rust's ocaml heritage, I'd imagine a straight port from typescript would be simpler and more idiomatic than a port to go. I guess not.

Rust memory management is very different from GC heap memory management.

While true, it has not prevented other Microsoft teams to port Typescript, and .NET code into Rust.

Notorious examples, the recent Github Copilot runtime, and the Microsoft 365 microservices.

Are you saying typescript idioms are significantly different from rust idioms (for a parser/grammar implementation) due to memory management?

The "shape" of the code would be different?

they wanted to do a direct line by line port. they evaluated rust and picked go because the gc let them keep code structure.

pretty much most nontrivial programs need to have a different shape to fit into the rust mindset.

For example i wrote a digital logic simulator. The last step involved a linking step to turn all indexes into pointers, once the component graph is generated in full and becomes stable in memory. The simulator just chased pointers.

In rust all of that would have either had to keep using indices, be highly non idiomatic by boxing everything (and slower), or implemented in unsafe rust.

If I have to write a lot of unsafe rust, then i would actually switch to cpp because unsafe c++ is easier to get right than unsafe rust

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

> you can spit out perfect machine level code against a specification

Typescript team explicitly mentioned the lack of Typescript specification as one of the reasons to choose Go. Typescript as the language is defined currently by its compiler which was Javascript based. Go port is as close to it as possible while Rust would be harder to reach fully identical behavior.

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

I agree, but certainly language constraints or features make analysis easier (and some analysis which was previously impossible now suddenly is) which in turn unlocks/enables a whole world of optimisations the compiler can do for you!

Reply on news.ycombinator.com