Do you have any plans to add timeouts or some other mechanism for limiting the amount of CPU a webassembly call can use?
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.
Congratulations on the progress and getting the engine out there!
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.
Thanks! Do you have a source for this? Would appreciate a pointer if you have one.
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).
Apple Developer Program License Agreement § 3.3.1.B, "Executable Code" [1]:
> 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.
> 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.
WASM seems to be rather poorly documented in general. I used to
think it is only badly documented in Ruby (which it is), but I
have been slowly reading "WebAssembly The Definitive Guide" and
when comparing this to information on the internet, it seems
WebAssembly is years behind e. g. HTML, CSS, or JavaScript in
regards to documentation. Granted, it is not the same user base
(more people will be interested in HTML and CSS simply because
there is a bigger pool of people interested in that, rather than
in WebAssembly), but still - documentation appears to become
really worse in general on the internet. Finding it too.
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.
Nice! I started building a toy Go WASM VM myself but a few hours in realized I was in way over my head. Seems very readable, I'm going to want to go to school on this!
Seems like a next step would be automatic code generation to map user-supplied (or auto-generated) interface definitions to exported WASM module functions.
Only tangentially related, asking out of curiosity.
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.
16 comments
[ 5.0 ms ] story [ 42.4 ms ] threadAlso: would be nice to see wazero (https://github.com/wazero/wazero) mentioned. What was the reason to create Epsilon as an alternative?
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-... )
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...
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.
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.
>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
Seems like a next step would be automatic code generation to map user-supplied (or auto-generated) interface definitions to exported WASM module functions.
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?