[airforce1]

In my experience it is pretty difficult to make WASM faster than JS unless your JS is really crappy and inefficient to begin with. LLVM-generated WASM is your best bet to surpass vanilla JS, but even then it's not a guarantee, especially when you add js interop overhead in. It sort of depends on the specific thing you are doing.

I've found that as of 2025, Go's WASM generator isn't as good as LLVM and it has been very difficult for me to even get parity with vanilla JS performance. There is supposedly a way to use a subset of go with llvm for faster wasm, but I haven't tried it (https://tinygo.org/).

I'm hoping that Microsoft might eventually use some of their wasm chops to improve GO's native wasm compiler. Their .NET wasm compiler is pretty darn good, especially if you enable AOT.

[zozbot234]

I think the Wasm backends for both Golang and LLVM have yet to support the Wasm GC extension, which would likely be needed for anything like real parity with JS. The present approach is effectively including a full GC implementation alongside your actual Golang code and running that within the Wasm linear memory array, which is not a very sensible approach.

[mappu]

The major roadblocks for WasmGC in Golang at the moment are (A) Go expects a non-moving GC which WasmGC is not obligated to provide; and (B) WasmGC does not support interior pointers, which Go requires.

https://github.com/golang/go/issues/63904#issuecomment-22536...

[zozbot234]

These are no different than the issues you'd have in any language that compiles to WasmGC, because the new GC'd types are (AIUI) completely unrelated to the linear "heap" of ordinary WASM - they are pointed to via separate "reference" types that are not 'pointers' as normally understood. That whole part of the backend has to be reworked anyway, no matter what your source language is.

[mappu]

Go exposes raw pointers to the programmer, so from your description i think those semantics are too rudimentary to implement Go's semantics, there would need to be a WasmGC 2.0 to make this work.

It sounds like it would be a great fit for e.g. Lua though.

[zozbot234]

I don't think Go supports any pointer arithmetic out-of-the-box? What it has in the base language is effectively references.

[pjmlp]

It does, via unsafe package, yes it does look ugly, that is on purpose.

    item := *(*int)(unsafe.Pointer(uintptr(start) + size*uintptr(i)))

A random example taken from Internet.

[mappu]

It also has an address-of operator, you can take the address of the middle of a large array.

I suppose that would be possible with fat-pointers that are reference+offset.

[yencabulator]

You can get a pointer inside a struct ("interior pointers") without pointer arithmetic.

[nicoburns]

> the Wasm GC extension, which would likely be needed for anything like real parity with JS

Well, for languages that use a GC. People who are writing WASM that exceeds JS in speed are typically doing it in Rust or C++.

[maxloh]

Yeah. If I remember it correctly, you need to compile the GC to run on WASM if the GC extension is not supported.

[zozbot234]

The GC extension is supported within browsers and other WASM runtimes these days - it's effectively part of the standard. Compiler developers are dropping the ball.

[AndrewDucker]

The Wasm GC currently doesn't support the functionality needed by both Go and C#. (Interior pointers, for instance)

I'm hoping that a later version makes this possible.

[DanielHB]

I did some perf benchmarks a few years ago on some JS code vs C code compiled to WASM using clang and running on V8 vs the same C code compiled to x64 using clang.

The few cases that performed significantly better than the JS version (like >2x speed) were integer-heavy math and tail-call optimized recursive code, some cases were slower than the JS version.

What I was surprised was that the JS version had similar performance to the x64 version with -O3 in some of my benchmakrs (like float64 performance).

This was a while ago though when WASM support had just landed in browsers, so probably things got better now.

[pjmlp]

Apparently not good enough, given the decision to use Go.