4 ms·

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

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.

maxloh 2y ago
Yeah. If I remember it correctly, you need to compile the GC to run on WASM if the GC extension is not supported.
- zozbot234 2y ago
  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 2y ago
    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.
mappu 2y ago
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-2253658466 https://github.com/golang/go/issues/63904#issuecomment-22536...
- zozbot234 2y ago
  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 2y ago
    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 2y ago
      I don't think Go supports any pointer arithmetic out-of-the-box? What it has in the base language is effectively references.
      - pjmlp 2y ago
        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.
        zozbot234 2y ago
        That's not the base language, it's an unsafe superset. There's no reason why a Wasm-GC backend for Golang should be expected to support that by default.
        pjmlp 2y ago
        If it is part of the language reference it is part of the language. Usually when language reference books used to be printed, or we used ISO languages, what is there on paper, is the language. We are only discussing semantics, if it is hardcoded primitives, or made available via the standard library, specially in case of blessed packages like unsafe which aren't fully implemented, rather magical types for the compiler. Hence why the only thing you will see here is mostly documentation, https://github.com/golang/go/blob/master/src/unsafe/unsafe.go https://github.com/golang/go/blob/master/src/unsafe/unsafe.g... Which is nothing new since the 1960's that there are systems languages with some way to mark code unsafe, the C linage of languages are the ones that decided to ignore this approach.
nicoburns 2y ago
> 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 2y ago

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

zozbot234 2y ago
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 2y ago
  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.

mappu 2y ago

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-2253658466 https://github.com/golang/go/issues/63904#issuecomment-22536...

zozbot234 2y ago
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 2y ago
  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 2y ago
    I don't think Go supports any pointer arithmetic out-of-the-box? What it has in the base language is effectively references.
    - pjmlp 2y ago
      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.
      - zozbot234 2y ago
        That's not the base language, it's an unsafe superset. There's no reason why a Wasm-GC backend for Golang should be expected to support that by default.
        pjmlp 2y ago
        If it is part of the language reference it is part of the language. Usually when language reference books used to be printed, or we used ISO languages, what is there on paper, is the language. We are only discussing semantics, if it is hardcoded primitives, or made available via the standard library, specially in case of blessed packages like unsafe which aren't fully implemented, rather magical types for the compiler. Hence why the only thing you will see here is mostly documentation, https://github.com/golang/go/blob/master/src/unsafe/unsafe.go https://github.com/golang/go/blob/master/src/unsafe/unsafe.g... Which is nothing new since the 1960's that there are systems languages with some way to mark code unsafe, the C linage of languages are the ones that decided to ignore this approach.

nicoburns 2y ago

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