all: add GOOS=wasip2 port

[mauri870]

WASI preview 2 was officially released.

With the launch of preview2, preview1 will be deprecated and transitioned to legacy support across various tools. For instance, the documentation for wasmtime indicates that legacy code will be removed after 2 releases after the landing of preview 2.

The main differences between WASI Preview 1 and Preview 2 are:

• Capability-based Security: WASI Preview 2 introduces capability-based security principles, using the facilities provided by the Wasm component model. All access to external resources is provided by capabilities. Handles, defined in the component-model type system, dynamically identify and provide access to resources.

• Modularity: WASI Preview 2 uses the component model's worlds mechanism to allow specific sets of APIs to be described which meet the needs of different environments.

• New Interface Definitions: For those familiar with WASI preview 1, interfaces have been adapted to use high-level types defined by the Component Model and are defined with WIT, including WASI IO, Filesystem, Clocks, and Random. A WIT package is a collection of WIT interfaces and worlds. A world is a complete description of both imports and exports of a component and may be used to represent the execution environment of a component

When we get a stable GOOS=wasip2 we might have to think on ways to deprecate (or remove) wasip1 in a future Go version.

It should be possible to "bridge" preview1 and preview2 in such a way that preview1 programs still work on preview2.

---

This issue now tracks discussions and feature requests regarding the new port.

Related Issues

GOOS=wasip1 tracking issue

cc @golang/wasm

[johanbrandhorst]

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.

[mauri870]

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?

[cherrymui]

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

[ydnar]

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

[ydnar]

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

[johanbrandhorst]

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.

[Malix-Labs]

I was an enthusiast about WASIp2

I am not anymore

https://kerkour.com/webassembly-wasi-preview2 by @sylvain101010 summarizes my concerns

[nickchomey]

This recent announcement looks very promising for using wasip2 with tinygo. In fact, I think some in this thread were even involved in it. Congrats!

So, I'm wondering if this issue might be moving along at all to bring broader wasip2 support to Go?

[johanbrandhorst]

A group of interested individuals is working towards making wasip2 possible, but precursors to that include #63131, #65199 (in development) and #66984 (in review). Once these are accepted and implemented we might be able to produce a wasip2 proposal. If you want to contribute to this effort, you can read through the issues and associated CLs, and join the discussion in #webassembly on the Gophers slack. Remember that all the webassembly work in Go has been designed and implemented by volunteers, not the Go team, so timelines are dependent on availability of volunteers.