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

Presumably because Rust is more suitable than Go in agentic coding? (I'm not sure, but that seems the purported answer.)

Rust is better at targeting WebAssembly

Rust is more close to metal. No GC

Was it ever a reasonable choice? At the time the choice was made the tooling ecosystem was already split between Rust and JS, and by putting TS in Go they chose to split it three ways. Why not split it 4 or 5 ways then? The pressure will always be towards less duplicated work.

The only real choice of language to build the next generation of JS tools in is JS. Anything else is a vote of no confidence in ourselves.