[simonw]

I disagree with this section about WebAssembly:

> 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!

[syrusakbary]

I also disagree with that.

Wasmer can run now Python server-side without any restrictions (including gevent, SQLAlchemy and native modules!) [1] [2]

Also, cool things are coming on the JS land running on Wasmer :)

[1] https://wasmer.io/posts/greenlet-support-python-wasm

[2] https://wasmer.io/posts/python-on-the-edge-powered-by-webass...

[saghm]

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.

[syrusakbary]

Not right now but we would love to provide it.

We have been super busy lately, but when we have a chance we will work on it!

[saghm]

Totally fair! I definitely understand the struggle of having more things that you want to do than time to work on them, and it's better to focus on the priorities and do them well than rush things just to get more of them done faster. Thanks for the response though; there's enough stuff happening in the WASM ecosystem that I don't always have confidence about whether I missed something!

[rcarmo]

Without any restrictions except, well, performance, and still a fair amount of library choices. It’s just easier to use Go (TinyGo, actually) instead.

[shayonj]

Wasmer looks v cool. I must check it out

[saghm]

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

[simonw]

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.

[saghm]

Looking again at the article though, it seems like they've added a paragraph after that references your response. The paragraph you quoted from isn't marked as edited, so I'm not sure if this was there before, but at least right now there's additional context coming immediately after your quote that I feel like conveys more nuance than it seems like you're addressing:

> For sandboxing arbitrary code in arbitrary languages, WASM is not yet viable. For sandboxing code you control the toolchain for, it is excellent.

That sounds pretty definitively like they're saying it is a great practical solution for many cases, not "ruling it out" like you mentioned in your top-level comment. It sounds more like they're saying it's not currently a black-box that you can run arbitrary code in, which is what some people might want in a sandbox.

[simonw]

> It sounds more like they're saying it's not currently a black-box that you can run arbitrary code in, which is what some people might want in a sandbox.

Yes, that's exactly what they are saying and it's true.

My comment (which they took on board) was to point out that, despite that, Python and JavaScript in WASM works really well if you take the extra steps of including a WASM-compiled build of the relevant interpreters.

I stand by my advice in this line:

> So don't rule out WASM as a target for running non-compiled languages, it can work pretty well!

You shouldn't rule out WASM for this purpose! I think it's likely people could read their original article and come to the wrong conclusion about that.

[saghm]

> I think it's likely people could read their original article and come to the wrong conclusion about that.

Fair enough; I think that's the part that I was missing. I might have been biased from having looked into this for Python recently and having a fairly high confidence in what those extra steps are, which could have made me overlook that others might not realize that those extra steps are even possible.

[shayonj]

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!