[adrianfcole]

(wazero maintainer) The default implementation will compile WASM to assembly not at runtime, but AOT (during Runtime.CompileModule). This allows more consistent performance and also more errors to materialize before a function call occurs. Compilation is automatic and also transparent (via mmap not files you configure), so you don't need to do anything special.

waPC [1] (used by some things like kubewarden) is an example of a plugin system, and its go integration [2] is one of the few things currently using wazero. It also integrates with alternatives such as wasmer and wasmtime, so you can look at the code to see how things are different.

We were intentionally hush about the project as we finish version 1.0, so weren't pushing for a lot of integrations, rather serving early adopters. Hence, wapc-go is currently the main victim of our api ;)

hope this helps!

[1] https://wapc.io/ [2] https://github.com/wapc/wapc-go

[skybrian]

To clarify the terminology, by AOT do you mean that the WASM needs to be compiled as part of the build of the Go executable that uses it, or just that it gets compiled before running the WASM code?

[adrianfcole]

nope this is all under the scenes. We formerly called this JIT, which was inaccurate but removed this confusion. Calling it AOT is more precise, but people ask this question. win some you lose some I guess!

Anyway, if you use `wazero.NewRuntime()` magically it redirects to `wazero.NewRuntimeCompiler()`[1]. When the compiler is in use, all the native stuff happens automatically and you don't need to change your binary based on the wasm you use.

This is actually neater than it seems as embedded compiler is goroutine safe, meaning you can compile modules concurrently.

https://pkg.go.dev/github.com/tetratelabs/wazero#NewRuntimeC...