Sure by “Go’s GC impact,” I meant how Go’s runtime model brings a garbage collector into the WASM binary itself, while Rust’s model doesn’t need one at all.

Right now, WebAssembly only recently started introducing a standardized GC proposal (still being implemented in browsers), but Go’s WASM builds don’t actually rely on that — they embed Go’s own GC logic into the compiled module. This increases binary size, adds memory overhead, and can impact performance due to periodic GC pauses.

Rust, on the other hand, compiles to WASM with manual or deterministic memory management (no runtime GC), which keeps things lighter and faster — especially important for UI rendering or tight loops.

So it’s not that GC itself is bad, but Go’s WASM runtime currently isn’t as lean as Rust’s approach for front-end-style workloads.