Comment by tgv
13 hours ago
Idk. Apart from the fact that benchmarks are generally of questionable value, what's the point? Is the TS compiler unbearably slow?
13 hours ago
Idk. Apart from the fact that benchmarks are generally of questionable value, what's the point? Is the TS compiler unbearably slow?
They say the point in the article - WASM
(Not sure if this could be a genuine remark or is more of a joke, but)
Why not vibecode a Go -> WASM cross-compiler, then?
Go needs a garbage collector while rust doesn’t.
9 replies →
You already can run the Go tsc in WASM using mature tools; but it further amplifies the memory and performance difference between the Rust version (which maps more cleanly onto WASM's design).
1. Porting typescript is made easier by the enormous test suite they can copy for verification.
2. They're doing this for workers, so with a systems-level language, there's a much higher potential for CPU and memory savings (an order of magnitude on this first pass, apparently). Driving their compute costs down is very revenue-efficient at this scale.
2 replies →
The success of "modern" CLI tools written in Rust (uv, oxlint, turbopack) show there's a clear demand for faster tools in general.
Also, faster feedback loop is crucial for AIs, so I guess this makes sense.
What they show is that JavaScript should never have left the browser into the backend.
Don't rewrite into Rust, Go, Java, .NET, Zig, Odin, whatever.
Start with them directly.
> Is the TS compiler unbearably slow?
It's not. Even the JS compiler is still fast enough for many projects given the single core improvements in hardware (eg Apple Silicon).
Faster feedback loops almost always deliver improvements elsewhere.
[flagged]
[dead]