Go: ergonomics improvement for types, function and package name

[Mossaka]

This issue is created for a discussion on improving how types, function and package named in the Go bindgen.

To see how the current names is generated, please read the head of this https://github.com/bytecodealliance/wit-bindgen/issues/612#issue-1801773199.

A summary of what's being proposed: https://github.com/bytecodealliance/wit-bindgen/issues/612#issuecomment-1644691976

[ydnar]

Some thoughts on this, from discussions at Wasmcon, and my work on the Go bindings generator:

Worlds vs Interfaces

We need to clarify if a Go program will presume an entire WASI world, or can link to individual packages or interfaces.

For example, will a Go program require the host implement the wasi:cli command world? Or be able to link to and use its constituent parts, e.g. wasi:clocks/monotonic, or wasi:random?

Names

As @Mossaka and others have pointed out, the current names generated by wit-bindgen can be long and cumbersome. I think it makes sense to map the WASI package name + interface into a Go package path, e.g.:

• wasi:clocks/monotonic-clock → <prefix>/wasi/clocks/monotonic-clock

Therefore the type wasi:clocks/monotonic-clock.instant would map to the Go type <prefix>/wasi/clocks/monotonic-clock.Instant.

Second, I think it makes sense to introduce a mapping of WASI names to Go names. This could be specified as command-line arguments to the Go code generator, or loaded from a config file. For example:

• wasi:clocks/monotonic-clock → <prefix>/wasi/clocks/monotonic (omitting the -clock suffix)
• wasi:clocks/wall-clock.datetime → <prefix>/wasi/clocks/wall.DateTime (explicitly naming a type)

Package path mapping would allow generated code to be placed in an internal directory, so the package author has control over the exported interface, say mapping WASI semantics to Go semantics (e.g. net/http interfaces). This would have the advantage of allowing the Go code generation to iterate without breaking external compatibility for dependent packages.

Stdlib

@achille-roussel pointed out that the requirements for codegen in the Go stdlib may differ materially, such as the number and names of generated Go packages, and how to make tradeoffs between simple vs clever or idiomatic vs performant.

[ydnar]

Follow up to previous comment, we now have working Go bindings generated from WIT:

https://pkg.go.dev/github.com/ydnar/wasm-tools-go/wasi

wit-bindgen-go can generate Go bindings from WIT:

wit-bindgen-go generate ./path/to/wasi-cli/wit # if wasm-tools is in path

Or:

wasm-tools component wit -j ./path/to/wasi-cli/wit | wit-bindgen-go generate

These are currently being used in a wasip2 port of TinyGo.