b01effc8a9
While compilers should be conservative when targeting WebAssembly Core features, runtimes should be lenient as otherwise people need to constantly turn on all features. Currently, most examples have to turn on 2.0 features because compilers such as AssemblyScript and TinyGo use them by default. This matches the policy with the reality, and should make first time use easier. This top-levels an internal type as `api.CoreFeatures` and defaults to 2.0 as opposed to 1.0, our previous default. This is less cluttered than the excess of `WithXXX` methods we had prior to implementing all planned WebAssembly Core Specification 1.0 features. Finally, this backfills rationale as flat config types were a distinct decision even if feature set selection muddied the topic. Signed-off-by: Adrian Cole <adrian@tetrate.io>
Basic example
This example shows how to extend a Go application with an addition function defined in WebAssembly.
Ex.
$ go run add.go 7 9
7 + 9 = 16
Compilation
wazero is a WebAssembly runtime, embedded in your host application. To run
WebAssembly functions, you need access to a WebAssembly Binary (Wasm),
typically a %.wasm file.
add.wasm was compiled from add.go with
TinyGo, as it is the most common way to compile Go source to Wasm. Here's
the minimal command to build a %.wasm binary.
cd testdata; tinygo build -o add.wasm -target=wasi add.go
Notes
- Many other languages compile to (target) Wasm including AssemblyScript, C, C++, Rust, and Zig!
- The embedding application is often called the "host" in WebAssembly.
- The Wasm binary is often called the "guest" in WebAssembly. Sometimes they
need imports to implement features such as console output.
TinyGo's
wasitarget, requires WASI imports.