I feel you and I also think this is a tough time. I routinely use Claude even though he typically ignores me ;) I'm also a maintainer of Goose and have been engaged since before the rust rewrite. I'll admit I don't get exactly what I want out of any agent. I also don't buy the "it is you" thing that is typical with Agents. We often need to know too many things and are defensive in how we act. I truly hope this is temporary.
ok back to the point. Block is not trying to sell a frontier model, or Goose at all. As an open source enthusiast, I like this model (no pun intended). Features go where the prominent site or key contributors want, vs a commercial agenda. To get more practical, it was goose folks themselves who put themsemselves out there in tbench.ai and remain in the top 10
Does this invalidate poor experience on use cases. no way. However, there's a lot of work being done by block folks to help teach and share practice and get things together. I'm always looking for pure local everything and Mic is also super keen on this, Today? well it is like watching someone type each character at a time while your laptop melts. I don't think this invalidates the long term, but it acknowledges the short term.
Next, Goose doesn't care about you in a specific way. Literally there is a Claude agent so you can swap out the goosey parts if you like. It is clunky and I'm personally looking into aligning that interop via Zed's ACP. I think like the combination of openness and not having any angle.. like not anti claude, literally give you a way to use it.. is telling.
This is a ramble and maybe a waste of your context, but I hope it colors some things and will get to see you around.
Adding a quick note as someone who contributes to Goose but isn’t a maintainer. I agree with a lot of what you’re saying. The harness and overall UX have changed quite a bit recently, though it’s still very much evolving like everything else in this space. If anyone tried it a while back, the newer versions are worth a look. And any issues people hit in practice are genuinely useful for us to improve things.
(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."
ok back to the point. Block is not trying to sell a frontier model, or Goose at all. As an open source enthusiast, I like this model (no pun intended). Features go where the prominent site or key contributors want, vs a commercial agenda. To get more practical, it was goose folks themselves who put themsemselves out there in tbench.ai and remain in the top 10
https://www.tbench.ai/leaderboard/terminal-bench/2.0
Does this invalidate poor experience on use cases. no way. However, there's a lot of work being done by block folks to help teach and share practice and get things together. I'm always looking for pure local everything and Mic is also super keen on this, Today? well it is like watching someone type each character at a time while your laptop melts. I don't think this invalidates the long term, but it acknowledges the short term.
Next, Goose doesn't care about you in a specific way. Literally there is a Claude agent so you can swap out the goosey parts if you like. It is clunky and I'm personally looking into aligning that interop via Zed's ACP. I think like the combination of openness and not having any angle.. like not anti claude, literally give you a way to use it.. is telling.
This is a ramble and maybe a waste of your context, but I hope it colors some things and will get to see you around.