Thanks!

Forgot to put it on the article, but the latest Python requires the Wasmer rc.5 to run! (the final release will be coming very soon)

    curl https://get.wasmer.io -sSfL | sh -s "v6.1.0-rc.5"
    wasmer run python/python

> I've been trying to find a robust, reliable and easy way to run a Python process in WebAssembly (outside of a browser) for a few years. reply

What’s the use case? Is it the sandboxing? Is it easier than running Python in a container?

Everyday we grow closer to my dream of having a WASM based template engine for Python, similar to how Blazor takes Razor and builds it to WASM. I might have to toy with this when I get home.

Does this work for packages with C/C++ extensions e.g. numpy and scipy?

``` ╰─ wasmer run python/python

error: Spawn failed

╰─▶ 1: compile error: Validate("exceptions proposal not enabled (at offset 0x191a)")

```

Hasn't Pyodide been available for some years now?

Arguably/pedantically, Pyodide has had this for a while: see https://developer.nvidia.com/blog/sandboxing-agentic-ai-work... for a use case.

Wasmer's approach hints at faster cold starts and better overall performance; the benchmarking against pyodide is a bit unclear, and it's unclear to me whether that would make or break viability for a use case like this.

But one thing this does make possible is if your arbitrary script is actually a persistent server, you can deploy that to edge servers, and interact with your arbitrary scripts over the network in a safe and sandboxed way!

That's almost exactly what I want to do too. I've experimented a bit with QuickJS for this - there's a Python module here that looks reasonably robust https://pypi.org/project/quickjs/ - but my ideal would be a WebAssembly sandbox since that's the world's most widely tested sandbox at this point.

Depending on the language, GC is either implemented in userspace using linear memory, or using the new GC extension to webassembly. The latter has some restrictions that mean not every language can use it and it's not a turnkey integration (you have to do a lot of work), but there are a bunch of implementations now that use wasm's native GC.

If you use wasm's native GC your objects are managed by the WASM runtime (in browsers, a JS runtime).

For things like goroutines you would emulate them using wasm primitives like exception handling, unless you're running in a host that provides syscalls you can use to do stuff like stack switching natively. (IIRC stack switching is proposed but not yet a part of any production WASM runtime - see https://webassembly.org/features/)

Based on what I read in a quick search, what Go does is generate each goroutine as a switch statement based on a state variable, so that you can 'resume' a goroutine by calling the switch with the appropriate state variable to resume its execution at the right point.

We are actually going on another direction.

Philosophically speaking I believe we should not require a special version of pip to install packages, nor a "lite" version of Jupyter to run in WebAssembly.

We should be able to run Jupyter fully within the Wasmer ecosystem without requiring any changes on the package (to run either in the browser or the server).

What would "support other languages natively" give you that WebAssembly doesn't?

Ideally, sure, but that would increase the already enormous burden of building a standards compliant web browser. For a healthy web ecosystem it's important that not only trillion dollar companies can contribute or compete.

Maintaining a browser is already hard enough, it's a very tough sell to convince 3+ browser vendors to implement a new language with its own standard library and quirks in parallel without a really convincing argument. As of yet, nobody has come up with a convincing enough argument.

Part of why WebAssembly was successful is that it's a way of generating javascript runtime IR instead of a completely new language + standard library - browsers can swap out their JavaScript frontend for a WASM one and reuse all the work they've done, reusing most of their native code generator, debugger, caches, etc. The primitives WASM's MVP exposes are mostly stuff browsers already knew how to do (though over time, it accumulated new features that don't have a comparison point in JS.)

And then WASM itself has basically no standard library, which means you don't have to implement a bunch of new library code to support it, just a relatively small set of JS APIs used to interact with it.

Confusingly, "Serverless" doesn't mean there's no server. It means that you don't have to manage a server yourself.

My preferred definition of serverless is scale-to-zero - where if your app isn't getting any traffic you pay nothing (as opposed to paying a constant fee for having your own server running that's not actually doing any work), then you pay more as the traffic scales up.

Frustratingly there are some "serverless" offerings out there which DO charge you even for no traffic - "Amazon Aurora Serverless v1" did that, I believe they fixed it in v2.

Thanks for the feedback.

Normally, if you want to run your apps serverlessly you'll need to adapt your source code to it (both AWS Lambda and Cloudflare Workders require creating a custom HTTP handler).

In our case, you can run your normal server (lets say uvicorn) without any code changes required from our side.

Of course, you can already do this in Docker-enabled workloads: Google Cloud or Fly.io, for example. But that means that your apps will have long cold-start times at a way higher cost (no serverless).

Hope this makes things clear!

I believe "serverless" in this sense means "like AWS lambda". Theoretically you upload some small scripts and they're executed on-demand out of a big resource pool, rather than you paying for/running an entire server yourself.

It seems like a horrible way to build a system with any significant level of complexity, but idk maybe it makes sense for very rarely used and light routes?

"Serverless" means Function-as-a-service, think of it like CGI-bin scripts but you pay per execution.

Yes, running Wasmer Python package on iOS or Android is 100% doable.

In fact, we want to even run it on browsers.

We are small team, so we have to pick our battles very carefully, but we would welcome any patch to make it work (if it doesn't work already!).

"fast" is not "blazing fast"

What does that do? A static website with some language compiled to wasm running in the browser?

For a backend project in Java, I use Jep for Python interoperability and making use of Python ecosystem. It gives me a "non-restricted" Python to have in my Java code, something I'm quite happy with. Wondering how this compares to that .

See https://github.com/ninia/jep