Comment by msdz
16 hours ago
(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?
16 hours ago
(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.
Wasm GC is not an object-level GC yet. It's still a very low level bit buffer GC. It's closer to the memory page management of an operating system than anything like JS's own GC.
Apparently there were some design issues (raised and ignored) that made it unusable for many languages.
1 reply →
The JVM alone has, what, 4 different modern GCs now? Garbage collectors aren't really universal, so they can pose different issues for different languages.
1 reply →
Yes, of course, but couldn’t you have/make one in WASM too? (I have no clue how memory is allocated there)
Yes, and when you ship a Go WASM package it is already included. But it has a certain impedence mismatch with WASM since it is rolling its own stuff that WASM can't see, I believe the performance is a bit less good than it could be, and it results in very large WASM packages for small amounts of code.
Since a typescript compiler isn't "a small amount of code", you'd have to see specific numbers on the final WASM assembly size to know how relevant that is. I'd expect well-written Rust code to beat well-written Go code on final assembly size by some amount, which may or may not be relevant to any particular use case (since in a lot of cases one "couple dozen megabytes" is much the same as another when it really gets down to it, it's not like Go is going to be emitting gigabytes to Rust's hundreds of kilobytes or something). However I can't judge what AI-written Rust code versus well-written Go code would come out as. AI is not terribly good at being concise (he said, while writing this post between prompts fighting with an AI to make a PR much more concise than it currently is).
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.
Did you read TFA?
> Just a few weeks ago we announced supporting native Rust in Workers with the new Emscripten target for wasm-bindgen. When you run entire software build and deployment systems in tight loops on Workers, the benefits of a small memory footprint pay off quickly.