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>
Allocation examples
The examples in this directory deal with memory allocation concerns in WebAssembly, e.g. How to pass strings in and out of WebAssembly functions.
$ go run greet.go wazero
wasm >> Hello, wazero!
go >> Hello, wazero!
While the below examples use strings, they are written in a way that would work for binary serialization.
- Rust - Calls Wasm built with
cargo build --release --target wasm32-unknown-unknown - TinyGo - Calls Wasm built with
tinygo build -o X.wasm -scheduler=none --no-debug -target=wasi X.go - Zig - Calls Wasm built with
zig build
Note: Each of the above languages differ in both terms of exports and runtime behavior around allocation, because there is no WebAssembly specification for it. For example, TinyGo exports allocation functions while Rust and Zig don't. Also, Rust eagerly collects memory before returning from a Wasm function while TinyGo does not.
We still try to keep the examples as close to the same as possible, and highlight things to be aware of in the respective source and README files.