evacchi

what are your favorite events? :)

I'm interested in finding tiny models to create workflows stringing together several function/tools and running them on device using mcp.run servlets on Android (disclaimer: I work on that)

Hey! Author of the post here (I work at Dylibso). In case it was not clear, this is a pure-Java Wasm run-time. There is also an experimental Extism SDK built on top of it! https://github.com/extism/chicory-sdk

Why pure-Java? It's just a library! Pull it in and see if it works for you, you won't need to rely on any native dependency. With this version we are also shipping both an in-memory and an off-line translator from Wasm to Java bytecode.

Java 11+ :)

Shameless plug for Dylibso's latest beta launch :) https://www.getxtp.com/blog/meet-xtp

disclaimer: I work there

interesting that they are shipping their own libc https://github.com/orca-app/orca/blob/main/src/orca-libc/not...

I love corecursive! Keep up the good work @adam!!

it's getting there https://openjdk.org/jeps/8316779

and for reference see how it's done in wazero https://github.com/tetratelabs/wazero/blob/c397a402ad17e495a...

@ncruces and I are also contributors to wazero, so ask away if you have questions :)

they are for Truffle-based language implementations https://chrisseaton.com/rubytruffle/pldi17-truffle/pldi17-tr...

There is also alf.io

Maybe just the missing leading slash in the original reproducer? :)

I don't know what kind of use case you have in mind specifically, but wherever you would use a scripting engine, you can embed a small Wasm runtime instead and let your end-users pick their favorite* language

(*) as long as there is a toolchain that supports using it on Wasm :P

I am a fan of the Jacobin project! For your uses, you may also want to consider wazero [1], a pure-go WebAssembly runtime. Full disclosure: I am on the team :)

[1]: https://wazero.io/

FYI: this builds cleanly with WASI SDK and runs with no changes in a Wasm runtime if you're into that kind of thing

worth mentioning: https://github.com/stealthrocket/timecraft

full disclosure: I don't work on it, but the devs are committers/contributors to https://wazero.io (I am a wazero committer) :)

That is correct. It is a webassembly runtime that you can embed in your go project. There are also other wasm runtimes that run outside the browser, this is one written in Go

wazero is a wasm runtime, not a wasm compiler. For a compiler Go -> Wasm you should use tinygo or Go proper :)

so as for the first question, I'll refer to Adrian's reply on an older thread https://news.ycombinator.com/item?id=31415317

as for the second, that's an excellent question but I'll have to be honest and tell you that I am the n00b of the team and I don't know the answer :D

I can refer you to these possibly related docs

- https://github.com/tetratelabs/wazero/blob/main/RATIONALE.md...

- https://wazero.io/docs/how_do_compiler_functions_work/ (e.g. traps are handled on the Go side)

...and then my awesome team mates might get back to you with a proper answer later when they wake up :^)

We are tracking the evolution of most proposals but we are a tiny team so we try to concentrate our efforts on those that have a higher degree of maturity, but I am sure we will at some point :)

it's a bit more nuanced than that, we are also trying to actually limit third-party dependencies, you can read more about it here https://github.com/tetratelabs/wazero/blob/main/RATIONALE.md...

tinygo still wins for size, and the reflection story got better (json works!). The traditional Go compiler produces larger binary but OTOH it's super-fast, as fast as native builds!

The "zero-dependency" in this context really means zero dependencies from Cgo :) see https://news.ycombinator.com/item?id=36552401

wasmtime and wasmer are basically state-of-the-art. Our compilation backend is a fast, but straightforward translator from wasm to binary (think v8 liftoff vs turbofan), so it's faster than interpreting, but still slower than a well-crafted optimizing compiler. However depending on your use case, that kind of performance may not be everything: e.g. when I/O dominates .

The good news is an optimizing backend is being worked on as we speak and should be available very soon :)

you mean like this? https://github.com/knqyf263/go-plugin ;)

wazero under the hood, by one of our awesome community members

we have our own assembler for arm64 and asm64

as far as I know wazero is the only zero-dependency Wasm runtime written in Go.

This is not just one of those "written in $LANG" kinda deal: most other runtimes require linking against a native library; this in turn plays against a lot of the killer features of Go, such as good tooling, easy cross-compilation, goroutines [0]; so, not requiring Cgo means a team may bring wazero to their Go project without a second thought.

As for other features, we may not be as bleeding edge as other projects, but we are a rather tiny team. If you expect support for WASI (preview 1) we have it :) we try to concentrate our effort on high-quality support of stable specs.

EDIT: oh, and a huge shout-out to Stealthrocket, they are building a lot of cool stuff on top of wazero:

- wzprof, a wasm profiler integrating with pprof https://github.com/stealthrocket/wzprof

- timecraft, a wasm time-traveling runtime https://github.com/stealthrocket/timecraft

[0] see "CGO is not Go" https://dave.cheney.net/2016/01/18/cgo-is-not-go

It depends on what you mean for JIT. wazero is load-time AoT; i.e. we compile the module in-memory on load, for efficient execution later, when you instantiate, it is not AoT in the sense that we produce a stand-alone executable, the runtime is always hosting that executable code that is generated, and we go back-and-forth between translated wasm and "Go space" at run-time in many cases. It is AoT in the sense that we do not tune the generated code depending on tracing or profiling information, because we don't track it for compilation.

The Wasm model itself gives a certain degree of safety: e.g. you do not have complete control over the host OS, because you have to explicitly expose functions to the gues module; we also provide a certain degree of control over e.g. execution time (you can instantiate a module in such a way that executions can be cancelled or set a timeout) and memory space.

We also provide an interpreter for all platforms where Go runs, and Takeshi (the founder of the project) is also working on bootstrapping an optimizing compiler that should soon land on main, and more work will happen in that space.

Hey I am on the dev team if someone has questions :)