One nice thing about interpreters versus JIT compilers is that they can be used in places like iOS without too much fuss (AFAIK you have to bundle all the WASM you will run though, or something like that).
I'm biased since I work on it, but any considerations around adding support for the Component Model? It's more complex than the base spec of course but incredibly robust -- really the present/future of "modern" WebAssembly across languages.
IIRC there is also a limitation on making platform-like super-apps on iOS and it feels like that might be a natural occurrence depending on just how much dynamic functionality you pull in via Wasm (i.e. how powerful your app is).
> Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application (b) does not bypass signing, sandbox, or other security features of the OS; and (c) for Applications distributed on the App Store, does not create a store or storefront for other Applications.
App Review Guidelines § 2.5.2, "Software Requirements" [2]:
> Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
1: https://developer.apple.com/support/terms/apple-developer-pr...
2: https://developer.apple.com/app-store/review/guidelines/#sof...
Also, there is an adapter for automatically taking p1 components to p2, and a p2 to p3 adapter may exist in time, if desire is great enough! IIRC it doesn't exist right now.
So in this regard, having more implementations may be useful (more opportunity to improve documentation) - thus while I am in general skeptical, this is good news here, even if I do not use Go myself.
It becomes a huge pain in the bum as soon as you have to deal with moving anything more than trivial types around, because you have to manually allocate memory for the WASM runtime and move bytes around. The byte representation needs to be understandable by the source language for your WASM code (the v language in my case). This is why these WASM runtimes use ints in their README examples, it would look and be horrendously complex otherwise.
If one is looking to use WASM for something for plugin development in the backend, I would try and look for something that is not WASM generic, but works with the source language, and where the WASM aspect is an under-the-hood detail.
I'm not sure how well it carries over to embedded platforms though, but I'm really interested in trying.
Or occasionally I Google specific Wasm instructions and find .wat examples for them on MDN.
I'm sure you're right that the documentation is years behind that of HTML and CSS, but is there some specific aspect of Wasm documentation that you find lacking that isn't covered by the spec?
I'm not sure if it's right but I think of WASM as just an ISA and I guess the documentation seems to cover instruction encodings and semantics.
I'm always interested in options for using WebAssembly as a sandbox to run untrusted code, but one of the things I need to protect against is an infinite loop.
(I had Claude knock up an experimental Python binding to try Epsilon out, notes from that here: https://github.com/simonw/research/tree/main/epsilon-python-... )
This lets it be handled asynchronously at the pace the host code chooses https://github.com/ringtailsoftware/uvm32
Funny that you built a Python wrapper as I originally started this implementation in Python, which was...not a good idea. Claude hallucinated the acknowledgments section though :D
(Core Wasmtime maintainer here, and I built our epochs mechanism when I realized we could do better than fuel if one doesn't need the determinism, only periodic yields)
Also: would be nice to see wazero (https://github.com/wazero/wazero) mentioned. What was the reason to create Epsilon as an alternative?
I wanted to build something fun, I did not check for existing implementations on purpose. I ended up putting more effort than I originally expected into this and now it's starting to look like it could be actually useful, almost by accident.
I'd be interested to understand the goal behind it better.
https://github.com/ncruces/go-sqlite3
Man I really enjoy golang and cross portability and wazero + sqlite could still be cross portable which is super fascinating
What are your thoughts on https://github.com/electric-sql/pglite (postgres in wasm)?
Also what were the goal behind a pure golang solution via wazero + wasm sqlite as you had made?
Was it cross platform support, if so, what are your thoughts on zig, I have seen a project use zig + golang to create cross platform C language support but I think that adding zig into the picture complicates the build process so there are tradeoffs and I am interested to hear your opinions about it!
It's pretty portable: with some caveats, it works pretty much everywhere Go does. Performance is bad outside amd64/arm64, but for most popular OS/platforms it's fine. See this for an overall picture (these are the platforms I test): https://github.com/ncruces/go-sqlite3/wiki/Support-matrix
I bet you could do the similar with pglite, but this (and helping out with wazero) already consumes all my spare time.
But I guess now that it's done, the comparison is obvious, and as a wazero maintainer, I wanted to know what we could learn from your experience.
>Looks inside
>0 dependencies
Wow. Amazing. Was that a planned feature or did you just manage to write the entire project without stepping out the go std lib?
Though to be fair, for tests I am relying on https://github.com/WebAssembly/wabt
If one wanted to have a JIT compiler from what I understand it would essentially need to be able to get a chunk of memory, generate instructions into it and then jmp there.
Is creating such a thing possible in just Go?
wazero does this, on amd64 and arm64: https://github.com/wazero/wazero
You can read more about the approach - from the creator - here: https://mathetake.github.io/posts/runtime-code-generation-in...
Seems like a next step would be automatic code generation to map user-supplied (or auto-generated) interface definitions to exported WASM module functions.
Is there anything akin to file sockets api for wasm? I see a lot of potential in using them with go channels for ipc between multiple wasm modules.
