adrianfcole

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

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.

some of us still remember ;)

(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.

$ echo salaboy | wazero run ruby-3.2.0.wasm -ne 'print "Hello "; print'

Hello salaboy

Of course getting and gems etc gets weird in wasm..

Anyway, thanks to VMware labs for publishing interpreter wasm builds, people can play around. https://github.com/vmware-labs/webassembly-language-runtimes...

Random, but enjoy.

(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.

A couple examples of this: * https://github.com/jerbob92/go-pdfium-wasm * https://github.com/ncruces/go-sqlite3

More here: https://wazero.io/community/users/

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.

https://github.com/tetratelabs/wazero/actions/runs/352306986... https://github.com/tetratelabs/wazero/tree/main/internal/int... https://github.com/tetratelabs/wazero/blob/main/Makefile#L32

Thanks for the analysis and good luck on things!

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.

my 2p and thanks for the post!

thumbs up and subscribe to this :) https://github.com/tetratelabs/wazero/issues/577

(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.

[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

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.

[1]: https://github.com/WebAssembly/proposals [2]: https://github.com/WebAssembly/meetings/blob/main/process/ph... [3]: https://webassembly.org/roadmap/ [4]: https://github.com/WebAssembly/gc

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.

https://pkg.go.dev/github.com/tetratelabs/wazero#NewRuntimeC...

(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 ;)

hope this helps!

[1] https://wapc.io/ [2] https://github.com/wapc/wapc-go

(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).

[1] https://github.com/tetratelabs/wazero/tree/main/examples/all...

(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.

[1] https://tinygo.org/docs/guides/webassembly/

(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)

[1] https://github.com/tetratelabs/wazero/tree/main/internal/int... [2] https://github.com/tetratelabs/wazero/runs/6472382559?check_...

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.

[1]: https://github.com/tetratelabs/wazero/issues/484 [2]: https://github.com/tetratelabs/wazero/issues/58 [3]: https://github.com/tetratelabs/wazero/blob/main/experimental... [4]: https://github.com/tetratelabs/wazero/issues/451