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