Wasm comes with a garbage collector though, no? So a garbage collected language that offloads all memory management to the runtime would actually be better than one that ignored the platform and does its own stuff.
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.
(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.
Wasm comes with a garbage collector though, no? So a garbage collected language that offloads all memory management to the runtime would actually be better than one that ignored the platform and does its own stuff.
6 replies →
Yes, of course, but couldn’t you have/make one in WASM too? (I have no clue how memory is allocated there)
1 reply →
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.
For workers, you only need to strip the types. There's no need to do the expensive checking.
1 reply →