3 ms·

Someone who's well versed can calrify that because Go is a language with garbage collection so does it mean it is not as suitable for targeting web assembly?

by wg0 3y ago

johncolanduoni 3y ago
Go exposes interior pointers to user code, so it will have some extra difficulty fitting into WASM GC’s current limitations. Similarly some of .NET’s recent GC features will probably clash with this interface. Honestly I think only languages with very simple GC semantics (e.g. JVM languages, scripting languages) will get much mileage out of it as currently specified.
- azakai 3y ago
  For now I think that's true. But there are plans to add features like interior pointers to WasmGC, that could allow a lot more eventually: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Post-MVP.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/Pos...
jerf 3y ago
I would characterize it more as Go is not a great language for WASM because of its relatively heavyweight runtime and a simple compiler that isn't focused on making small binaries (AIUI, no "tree shaking" whatsoever, once a module comes in you get 100% of it unconditionally) makes fairly large WASM binaries. The runtime model mostly works in WASM today but it has a few roughish edges that can get you in trouble (though similar rough edges are in many languages at the moment). If Go could depend on WASM having a GC, and if Go doesn't have some sort of critical semantic mismatch with what WASM implements... and it is shocking how small the mismatch has to be before it becomes a critical problem sometimes... then the Go WASM binaries could get smaller by not needing to ship a full GC. However, it's still going to be pretty large even so. It's probably a critical feature for Go to be able to go WASM and in the long term be able to use WASM-based code, because it's often important for it to at least be an option. But I seriously doubt any WASM-first project in the next several years is ever going to pick Go as its base. You start with an awful lot of compromises right off the bat. If WASM succeeds, it will slowly but surely start to escape the browser. When you're not in a browser anymore, and you have something like a WASM executable in hand that you want to run in some WASM environment for some reason, the tradeoffs get less bad, for much the same reason it is usually not that big a deal that Go executables can be a bit on the large side right now. But this is still years off. WASM's immediate future is in the browser, where the extra large runtime and build sizes is not necessarily a fatal objection, but a fairly significant cost right up front compared to a lot of alternatives.
- aatd86 3y ago
  There are actually plenty of wasm first projects in Go. And tinygo is an alternative compiler that implements another GC algorithm and aims at shipping small binaries, including wasm files.

Someone who's well versed can calrify that because Go is a language with garbage collection so does it mean it is not as suitable for targeting web assembly?

by wg0 3y ago

Someone who's well versed can calrify that because Go is a language with garbage collection so does it mean it is not as suitable for targeting web assembly?

johncolanduoni 3y ago

Go exposes interior pointers to user code, so it will have some extra difficulty fitting into WASM GC’s current limitations. Similarly some of .NET’s recent GC features will probably clash with this interface. Honestly I think only languages with very simple GC semantics (e.g. JVM languages, scripting languages) will get much mileage out of it as currently specified.

azakai 3y ago
For now I think that's true. But there are plans to add features like interior pointers to WasmGC, that could allow a lot more eventually: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Post-MVP.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/Pos...

jerf 3y ago

I would characterize it more as Go is not a great language for WASM because of its relatively heavyweight runtime and a simple compiler that isn't focused on making small binaries (AIUI, no "tree shaking" whatsoever, once a module comes in you get 100% of it unconditionally) makes fairly large WASM binaries. The runtime model mostly works in WASM today but it has a few roughish edges that can get you in trouble (though similar rough edges are in many languages at the moment). If Go could depend on WASM having a GC, and if Go doesn't have some sort of critical semantic mismatch with what WASM implements... and it is shocking how small the mismatch has to be before it becomes a critical problem sometimes... then the Go WASM binaries could get smaller by not needing to ship a full GC. However, it's still going to be pretty large even so. It's probably a critical feature for Go to be able to go WASM and in the long term be able to use WASM-based code, because it's often important for it to at least be an option. But I seriously doubt any WASM-first project in the next several years is ever going to pick Go as its base. You start with an awful lot of compromises right off the bat. If WASM succeeds, it will slowly but surely start to escape the browser. When you're not in a browser anymore, and you have something like a WASM executable in hand that you want to run in some WASM environment for some reason, the tradeoffs get less bad, for much the same reason it is usually not that big a deal that Go executables can be a bit on the large side right now. But this is still years off. WASM's immediate future is in the browser, where the extra large runtime and build sizes is not necessarily a fatal objection, but a fairly significant cost right up front compared to a lot of alternatives.

aatd86 3y ago
There are actually plenty of wasm first projects in Go. And tinygo is an alternative compiler that implements another GC algorithm and aims at shipping small binaries, including wasm files.