(wazero contributor) This is a fairly common problem in WebAssembly, jargon overload mixed with conflation. We're starting our own docs, and doing the rare thing of adding a terminology section to it ;) https://wazero.io/docs/
(wazero contributor) In case you are interested, you can use Ruby (or any other interpreter compiled to wasm) with wazero. Our CLI shows what most of the runtimes can do, too.
(wazero maintainer) Right now, there's no auto-magic repackaging, but it is extremely common to do manually in our ecosystem. Most will use go:embed to embed the wasm binary into the compiled application so it still appears all static linked, self contained at the end.
Note that often times a lot of work is porting because not all tools build well to wasm. This would apply for any runtime as we're just running the standard with some special extensions for emscripten, wasi etc.
(wazero contributor) thanks for the analysis. certainly dependency pain is something we hear about, as well as lack of maintenance on alternatives. Some don't release at all or rarely, and many break api constantly. We also break api, but then again we aren't 1.0 yet.
wrt performance, we do watch it closely, but we've not done benchmarks vs non-default settings in other runtimes. It is the case that the tradeoff of avoiding dependencies means any optimizing JIT would have to be written to make long running things faster over time... no one has contributed this, yet, and more folks are looking at short lived despite it being the case interpreters are a great example of long lived.
Concretely, we do keep track of relative performance (literally each commit in fact), and it isn't uncommon to find PRs including perf before/after.
here are some pointers if interested in digging in! there are certainly some things we'd lose at.
As a relative newcomer to WebAssembly, the first thing I noticed was a disconnect between WebAssembly, which is loosely governed by W3C process, whereas WASI, a subgroup, never released a draft, closest thing being the module id people tend to use, wasi_snapshot_preview1. The next surprise is finding most implementations usable by end users (ex language compilers, not necessarily wasi-libc), employ a small subset of the apis on a whack-a-mole basis. Then, you find that most attempts to have a test kit failed, and unlike the core spec which has a way to say if you passed or not, there's neither decent documentation, nor a test kit for wasi. Then, when issues are raised, some comments you mention about copy/paste CloudABI problems are conceded even by the project team. However, there's no usable infrastructure to bridge to what the next one is (I think based on component model, but supposedly usable without it).
My feeling is that the amount of surprised I had was brought about by the overwhelming marketing that WASI was basically this thing that gives you a capabilities based model for system calls, and in practice it was a semi-implemented, glorified markdown file that was not a part of any standardization process, at least not W3C draft..REC.
Now, I look at some of the tensions and they seem to imply this solved backend, but not frontend :) Well, I would say that it got backends turning, basically pushing the abstraction cliff a bit farther out than ad-hoc host ABIs times X targets. This surely was helpful as it allows people to get much farther along especially when everything uses llvm and libc. However, I hope what's next can do a bit more rigor as the first was an example of how to thrash a lot of people. spectest shouldn't be an optional thing in something called a standard, detailed mapping documents can happen to help people implement the paper and pass those tests. I think whatever happens next can fix things, and it will be both a matter of avoiding copy/pasta spec, but also adding far more rigor.
Regardless, I personally am happy to continue supporting who has used WASI and its alternatives including the next WASIs. Progress is important and I think WASI, albeit stumbling, progressed the backend a lot.
(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.
There's a proposals repo [1] that tracks the status of features like GC. According to that, GC is phase 2, which is prototyping [2]. To get to the finish line, implementations including at least 2 browsers need to happen (this is a Web standard, so there's some browser bias in the process). It is not straight forward to see who and what are implementing a proposal, especially if not tracked in the roadmap [3]. Best advice I could give for now is to watch the proposal repo [4], or just wait. It may be a while on this one.
(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 ;)
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?
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.
When explaining it, it might be a good idea to focus on a little more on what this technology can do for you: "How to add cross-platform plugin support to a Go program using WebAssembly."
(wazero maintainer) we have a popular allocation example, which shows how GC ends up embedded (really malloc/free) in wasm produced by Rust or TinyGo. You are right that whatever produces wasm, if needs to allocate memory, is doing that by embedding some implementation into the wasm (during compilation).
(wazero maintainer) no this doesn't really help with that. This runs wasm in Go, regardless of which language compiled to wasm. TinyGo [1] is the most popular option to compile Go into wasm, and they have some instructions for web browser embedding.