> But the practical limitation is language support. You cannot run arbitrary Python scripts in WASM today without compiling the Python interpreter itself to WASM along with all its C extensions. For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable.
Can you clarify what your disagreement is? The statement you're responding to seems to be that you can't necessarily run arbitrary code in arbitrary languages because it's only possible if the runtime is supported, and you're giving examples of two specific languages that had explicit extra work done to support them, which sounds pretty much exactly like what they're stating.
From what I can tell, the point they're making is that if you want a sandbox that you can put whatever you want into and have it work without it having explicit support provided for that language in the form of recompiling the runtime, it's not going to work. If someone is expecting to be able to throw stuff they already have into a sandbox as-is and have it work, WASM is not what they're looking for (at least not today).
It used Python as an example of why "For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable." - but Python in WASM works really well, as do other languages where the interpreter can be compiled to WASM.
So while the statement is technically true that you can't run "arbitrary code in arbitrary languages", the practical reality is that for many languages WASM is a great solution despite that.
Is the support for Python code provided as a Rust library by any chance, where you could do something like pass in a simple python function, run it in wasmer, and then get back the result? I know a lot of complications would come into play around supporting C-based dependencies and support for the WASM APIs for stuff like I/O, but I recently was looking into this for a use case where the goal is to be able to prevent stuff like direct use of I/O in favor of only supporting a few specific APIs provided directly to a WASM engine for the code it's executing, and the conclusion I reached was that the only viable options for that currently available would require either shelling out to something external or manually loading in a WASM-compiled interpreter and implementing the glue code to use that to execute Python myself.
That is a good call out and I missed to consider the options you pointed. When I am back on keyboard I will add an updated note with a link to your comment. Thank you!
> But the practical limitation is language support. You cannot run arbitrary Python scripts in WASM today without compiling the Python interpreter itself to WASM along with all its C extensions. For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable.
There are several versions of the Python interpreter that are compiled to WASM already - Pyodide has one, and WASM is a "Tier 2" supported target for CPython: https://peps.python.org/pep-0011/#tier-2 - unofficial builds here: https://github.com/brettcannon/cpython-wasi-build/releases
Likewise I've experimented with running various JavaScript interpreters compiled to WASM, the most popular of those is probably QuickJS. Here's one of my many demos: https://tools.simonwillison.net/quickjs (I have one for MicroQuickJS too https://tools.simonwillison.net/microquickjs )
So don't rule out WASM as a target for running non-compiled languages, it can work pretty well!