Hacker News Reader

Hacker News

Comment by ruther4d | Hacker News Reader

Parent Full thread

ruther4d

They say the point in the article - WASM

View on HN

(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.

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).

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.

Apparently there were some design issues (raised and ignored) that made it unusable for many languages.

Ignored is a little unfair to the Wasm committee, the Wasm GC is constrained by what is possible to ship in existing Wasm runtimes and the stuff needed by many languages is way beyond what those existing runtimes have available to them.

I think it made sense for them to compromise, at least on the initial version of Wasm GC, to get it out the door. I say this as someone who wants the features that got left out, like interior references :)

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.

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.

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.

Reply on news.ycombinator.com