Hacker News Reader

Comment by koolba | Hacker News Reader

> An experimental TypeScript port of the TypeScript 7.0.2 compiler (TypeScript-Go, or tsgo), compiled to native code with scriptc.

I don’t get it. Isn’t the golang version already native?

Or is this one of those things where it’s not supposed to make sense?

View on HN

"Native code" doesn't mean "as fast as the code can possibly be". The native code this produces is (apparently) better optimized than the code that the Go compiler produces. It's a given that the Go compiler will produce suboptimal code, if nothing else because it includes a garbage collector in the compiled code, which introduces overhead.

Is the Typescript not garbage collected somehow?

If "scriptc" is so invasive it makes Typescript no longer even a garbage collected language then it really isn't Typescript anymore.

My language was perhaps not as clear as it could be, given that we're talking about compiling compilers. This is about the native code of the compiler itself. The original Typescript compiler ran as regular JS inside a JS engine. The Go rewrite compiles the Typescript compiler to native code. This rewrite also compiles the Typescripter compiler to native code. In both cases, the Typescript compiler is now running directly on the OS rather than inside a JS engine, so both are significantly faster at compiling Typescript programs. However, the natively-running Typescript compiler compiled by Go still has a garbage collector itself. You don't need a garbage collector running while translating Typescript code to Javascript.

No, the question asked was whether binaries output by scriptc, such as the tsc-ts compiler binary, include a garbage collector that runs while they're running. (The question was not about the output of tsc-ts.) If not, then that would raise a bunch of questions about how the TypeScript code that was fed into scriptc is being executed without a GC. It is true that a TypeScript compiler could be written in a non-GC language like Rust, but tsc-ts in particular is written in TypeScript, which needs a GC.

The answer, according to https://scriptc.dev/docs/limitations#weak-collections-and-me..., is that scriptc relies primarily on reference counting, augmented with a cycle collector that runs at specific times, kind of like Python.

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.

Yes, I agree. I am just trying to clear up some base-level confusion about how other versions can be faster. The person who vibecoded the Rust port already said they won't maintain it. For obvious reasons! Maintaining a codebase you haven't read becomes significantly more difficult. LLM ports are easy when you have years and years of good human-written tests providing a deterministic guideline that cages them in. Even then, the fabled Bun "Rust port in 11 days", besides costing millions in tokens, introduced hundreds of bugs not caught by the tests and took over three months of human labour before being shipped as an actual release, and is still experiencing instability. And once you lose sight of the codebase, continuing to improve the software becomes a nightmare - LLMs can't write good tests, and humans can't write good tests either if they don't understand the code, so the philosophy of "write tests as the specification for LLMs to implement" only carries you so far.

Source on Bun still being less stable than before the rewrite?

This version can additionally be compiled through LLVM, using a compiler from Vercel supporting a subset of TypeScript. I tried and it is 2 to 3x faster than the native Go version.

So it's just the compiling that's faster? Still not clear on the point of this, I have some pretty absurdly large typescript projects and have never felt that the compiler was slow, even before 7

both tsgo and tsc-ts are native, tsc-ts is faster and still written in TypeScript. tsc-ts was built using scriptc, a TS-to-native compiler.

Reply on news.ycombinator.com