I'm a little confused, is this issue supposed to track discussion towards a separate proposal for how to implement this support? I don't know that an issue is going to be the best place to have those discussions (there's a LOT of exploration to do here). This doesn't look like a proposal on its own. Is there a reason you added the proposal label?

Regarding a potential wasip2/wasm port for Go, it's something I and others contributing to the wasm ports within Go are working towards, but we're not ready to produce a proposal yet. If you want to help with this, the #webassembly channel on the Gophers slack is a good place for discussions.

It was a bit naive of mine to mark this as a proposal, I understand the complexity and work necessary to implement preview2 and I agree that the bulk of the discussion should happen somewhere else. My intention was to raise the awareness to the release and create some kind of umbrella issue regarding the new port, but maybe it is too early to do so.

Maybe we can keep this open as a feature request and use it for updates or community feedback/request while the wasm team works towards a proposal?

Thanks for the issue. Do you have an estimate of how much work needed to be done based on our wasip1 implementation? Thanks.

@cherrymui some context:

WASI Preview 2 builds on the Component Model, which introduces a new ABI distinct from the C-style Core WebAssembly calling convention of WASI Preview 1.

We should consider the GOARCH=wasm32 and go:wasmexport proposals as prerequisites for a GOOS=wasip2 port:

• cmd/compile: create GOARCH=wasm32 #63131
• cmd/compile: add go:wasmexport directive #65199

Some of us have been working on implementing GOOS=wasip2 in TinyGo, along with the necessary code generation for WIT IDL files to Go.

The current generated Go bindings for wasi:cli/command can be found here: https://pkg.go.dev/github.com/ydnar/wasm-tools-go/wasi. The wit-bindgen-go tool that generated this was designed to output code suitable for inclusion in the Go standard library, e.g. syscall/wasm/wasi.

Another likely requirement for supporting GOOS=wasip2 is tooling, specifically whether the Go toolchain will be able to natively output a WebAssembly component, which differs from a core Wasm module.

Currently, the WIP TinyGo port for wasip2 uses wasm-tools to perform two post-processing steps on the compiled Wasm module emitted from the TinyGo compiler (wasm-tools component embed and wasm-tools component new):

wasm-tools component embed -w wasi:cli/command $(tinygo env TINYGOROOT)/lib/wasi-cli/wit/ main.wasm -o embedded.wasm
wasm-tools component new embedded.wasm -o component.wasm

This was discussed this morning in the Bytecode Alliance Go SIG meeting. The consensus was that Go should be able to natively emit a component, and not depend on an external program (e.g. wasm-tools).

Thanks for bringing that up Randy, it's something that I've thought about too (see #65199 (comment)). I agree that it would make sense for the output of wasip2/wasm to be a Wasm component, since the OS is explicitly WASI p2, not some generic Wasm environment. It's not clear to me yet what, if any, use cases there are for Go to output Wasm core modules.