I happen to work on a lot of profiling and debugging tools and I’ve been wondering if the wasm spec has included anything about the “debugability” of wasm binaries. After a quick scan of the table of contents I couldn’t find it but I’d be curious to hear from anyone who might know. I fear that with an explosion of wasm runtimes (this looks super cool but also I think the 4th or 5th wasm runtime I’ve noticed) that debugability will be a nightmare if it’s not in the spec.
I'm a maintainer on wazero. We have two things in progress on debugability, though both are stalled as we complete the recently announced WebAssembly 2.0 draft spec (nearly done) [1].
1. DWARF support - this requires those compiling to Wasm to configure to emit that. It is also murky because there's no canonical mapping in Wasm (most rely on LLVM underneath, but wazero is zero dependencies so we can't do that). Anyway, this is still on the table. [2]
2. Observability hooks - wazero is uniquely go-native which means we can do things like context propagation, allowing telemetry hooks including distributed tracing. While it may not seem intuitive to use that in Wasm, it can allow you to re-use tools that can show a trace graph. We have an experimental listener now, which has an example of how to make some strace looking logs. [3] Later, we'll convert this to an interceptor approach so that you can do metrics and stuff nicer. [4]
Regardless of this, debugging is easier because everything is in go. Apart from the DWARF thing which is totally important, the runtime being in Go completely means you debug everything going on, down to what is allocating memory, just by putting break-points in Go code. This is a very neat thing, and has helped some folks develop better code. Ex. https://github.com/inkeliz/karmem
Hope these help. Indeed the road to wasm is littered with a lot of runtimes, mostly abandoned or archived. We're hoping to buck the trend debugability, so watch the issues below if interested, and feel free to tell us anything we aren't doing right, too.
There's a proposed standard for embedding DWARF debug info in WASM binaries [1], which at least Chrome already supports. This is the same format native executables use, so it should put wasm ahead of other VMs in terms of source language independence. Dwarf seems to be the best thing we have, even if it's not renowned for its ease of use.
What features exactly are you looking for? I have only used emscripten but you can compile debug builds and step through the code in the browser's inspector.
I don't know enough about wasm runtimes, but for example JIT runtimes like nodejs (or JVM via perf-map-agent [0]) allow writing out debug infos via the Linux Kernel JIT-Interface [1], which debuggers and profilers can then pick up to symbolize stack traces. Not saying that it has to be the Linux JIT perf-map interface, but it'd be nice if it's something implementors of the runtimes kept in mind (not implying that they're not, I just haven't read anything).
Looks like the compiler includes support for amd64 and arm64 code generation. It's unclear if you can compile WASM to assembly at runtime and invoke it? If so, it might be a viable way to implement plugin support.
(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."
Could this be used to deploy Go CLI programs as web apps?
I haven’t worked with WASM before, but it seems like you should be able to sniff the CLI definition and expose the arguments and flags as basic web components / widgets.
(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.
(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.
You may want to consider not doing so; why host other languages if you can either write Go code, or write what your Go program does in said other languages? See also https://boringtechnology.club/
I recently finished building https://subzo.com.au which allows customizing and ordering 3D models. The way the model's cost, volume and other attributes are calculated needs to be done both on the frontend (for speed) and on the backend (to validate). Backend is in Go and we can't practically run Go in the browser. So instead, I wrote the calculation snippets in JavaScript (which runs natively in the browser) and ran them on the backend on a JavaScript VM library written in Go [1].
Hosting Go in Go is kind of an interesting idea! I enjoyed what I found on boring technology club and in general I agree, shipping is happiness, but! That's on the job. Outside of work I also do a bunch of stuff and there I do, uh... whatever. The point being that my personal projects are all about doing things I just wouldn't do at work, too much hassle. Anyway, I enjoyed the link.
It's pretty rude to walk around blasting a presentation at folks. You have no idea what their other requirements are. What if they need arbitrary user submitted code to be sandboxed and don't want to deal with cgo utilizing other wasm runtimes? Wazero seems pretty boring and perfect.
(from wazero maintainer) we run benchmarks [1] on every commit! Depending on host and CI weather, we sometimes don't win [2] (click the Run make.check thingy)
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.
Go has a runtime that has to be included, with GC running alongside the app. So no, it is not at all a good fit for Wasm, until the latter’s GC proposal gets finalized.
(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).
Emscripten is amazing if you need a full POSIX environment in a web browser. Everything is emulated through Javascript calls.
If you don't need that, or just need the WASI subset, you can simply use Zig to compile C/C++ code to WebAssembly ("zig cc -target wasm32-wasi"). Compilation is as fast as other targets.
