Comment

Comment by jchw

Go also just produces suboptimal code because it isn't maximally geared towards runtime performance. It lacks a lot of the more expensive optimization passes, like auto-vectorization.

On the other hand, time and time again it has been proven that it can be a good language to write tools that are perfectly sufficiently fast, like esbuild. With ts-go the choice to target Go instead of Rust seems to have come down to sensibilities and ease of translation, and possibly some other factors as well. I don't think they were aiming for maximum performance, and it would be unsurprising if you could squeeze quite a bit more out of ts-go itself with some effort.

The real benefit was getting the initial "10x" improvement, of course. Getting an additional 2x-3x is fantastic, but it's less noticeable when your codebase is already getting typechecked faster than you care to measure. For me even my largest codebases are chewed through plenty fast on ts-go, and I trust the TypeScript team to have done a good job (especially having seen some of their process for doing the port) so I think I'm good on missing out vibecoded Rust ports and whatnot. Interesting for sure, but we'll see how it all pans out in the long run.

parent jchw 14 days ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton