(wazero maintainer) thanks for asking the questions! I'll answer them below. First as TL;DR; then more explained.
TL;DR;
> whats the compiled size?
wazero adds less than 2MB to your binary with no strings attached.
> Any performance numbers?
yes, but unlike most projects we don't add numbers to our README
> How is it easier to access functions and types from WASM to Go, and vice versa?
Take a look at our examples, and let us know how easy it is? [5]
Long:
> whats the compiled size?
wazero adds less than 2MB to your binary with no strings attached.
Because wazero doesn't rely on CGO, you have the simplicity of counting only the size of the binary. In other words, there are no potentially large shared libraries you need to count, and certainly no glibc needed.
I made this example [1], which is the a basic calculater, and it makes a 3.3MB binary (go 1.18.2) slightly larger in Docker (3.4MB via FROM scratch). It used to be 3.1MB until we added WebAssembly 2.0 support which is really quite big. Meanwhile I think the smallest Go binary would be 1.7MB or so.
> Any performance numbers?
yes, but unlike most projects we don't add numbers to our README.
README numbers are instantly out of date. We might publish on cron or something, since people seem really interested.
We run benchmarks on every commit[2], and the results vary, but not in surprising ways. The most accurate benchmark is allocation [3], though most people seem to only benchmark math functions. allocation is more like what your real code would do, ex an envoy filter changing a header. I saved results from a recent run to save you some clicking [4]. Sometimes wasmer beats us in one of the benchmarks, and that's with their default config.
Besides speed of calling, we pay attention to both the performance and safety of instantiating a wasm module. Instantiation is when you create a new sandbox. Granted, this is a new project and speed wise we have work to do, but at least concurrency works. So you can safely use the same runtime and create a new sandbox even per request. If your wasm is small that could happen in <1ms.
> How is it easier to access functions and types from WASM to Go, and vice versa?
Take a look at our examples, and let us know how easy it is? [5]
We've worked on this quite a bit, and hope that we are doing ok on it. Basically wasm has "export" functions (sometimes called externs), and we have an api.Function[6] interface for calling regardless of who defined it.
We have a ModuleBuilder[7] which is how you define functions in go. These are explained by our examples [5]. For us, we mainly designed based on how we felt things could be in Go, feedback from users and also comparing against how others do it. Particularly, we looked at wapc-go [8] to ensure our API felt the leanest possible to achieve the same goal.
TL;DR;
> whats the compiled size?
wazero adds less than 2MB to your binary with no strings attached.
> Any performance numbers?
yes, but unlike most projects we don't add numbers to our README
> How is it easier to access functions and types from WASM to Go, and vice versa?
Take a look at our examples, and let us know how easy it is? [5]
Long:
> whats the compiled size?
wazero adds less than 2MB to your binary with no strings attached.
Because wazero doesn't rely on CGO, you have the simplicity of counting only the size of the binary. In other words, there are no potentially large shared libraries you need to count, and certainly no glibc needed.
I made this example [1], which is the a basic calculater, and it makes a 3.3MB binary (go 1.18.2) slightly larger in Docker (3.4MB via FROM scratch). It used to be 3.1MB until we added WebAssembly 2.0 support which is really quite big. Meanwhile I think the smallest Go binary would be 1.7MB or so.
> Any performance numbers?
yes, but unlike most projects we don't add numbers to our README.
README numbers are instantly out of date. We might publish on cron or something, since people seem really interested.
We run benchmarks on every commit[2], and the results vary, but not in surprising ways. The most accurate benchmark is allocation [3], though most people seem to only benchmark math functions. allocation is more like what your real code would do, ex an envoy filter changing a header. I saved results from a recent run to save you some clicking [4]. Sometimes wasmer beats us in one of the benchmarks, and that's with their default config.
Besides speed of calling, we pay attention to both the performance and safety of instantiating a wasm module. Instantiation is when you create a new sandbox. Granted, this is a new project and speed wise we have work to do, but at least concurrency works. So you can safely use the same runtime and create a new sandbox even per request. If your wasm is small that could happen in <1ms.
> How is it easier to access functions and types from WASM to Go, and vice versa?
Take a look at our examples, and let us know how easy it is? [5]
We've worked on this quite a bit, and hope that we are doing ok on it. Basically wasm has "export" functions (sometimes called externs), and we have an api.Function[6] interface for calling regardless of who defined it. We have a ModuleBuilder[7] which is how you define functions in go. These are explained by our examples [5]. For us, we mainly designed based on how we felt things could be in Go, feedback from users and also comparing against how others do it. Particularly, we looked at wapc-go [8] to ensure our API felt the leanest possible to achieve the same goal.
[1]: https://gist.github.com/codefromthecrypt/edb33284354d592dc60... [2]: https://github.com/tetratelabs/wazero/blob/main/.github/work... [3]: https://github.com/tetratelabs/wazero/blob/main/internal/int... [4]: https://gist.github.com/codefromthecrypt/48877abc4b3ba5ceca1... [5]: https://github.com/tetratelabs/wazero/tree/main/examples [6]: https://pkg.go.dev/github.com/tetratelabs/wazero/api#Functio... [7]: https://pkg.go.dev/github.com/tetratelabs/wazero#ModuleBuild... [8]: https://github.com/wapc/wapc-go/tree/master/engines