syrusakbary

Love your profile. I just wish you were based in Europe (we are hiring in Europe at Wasmer)

Same! Pi is incredibly exciting.

We launched Pi support in Wasmer a few days ago and reception has been great (so you can run pi in your iPhone or browser, or even embedded)

We have set up this demo, if you want to try Pi 1.0 online: https://wasmer.sh/?example=pi

(for an easter egg click on the Pi logo on the top left!)

Nice!

This is great. A few days ago we were able to enable running Pi fully in the browser (and in the iPhone). Demo here: https://wasmer.sh/?example=pi

I'd be curious if we could compile Rpi to WASIX (https://wasix.org) and get it there as well!

I believe it captures each of the frames as png and then ffmpeg puts them together as a video. Although someone from Anthropic may be able to explain this better

Indeed, it's really great. It does the smartest thing of all: it creates an HTML page and uses raw JS timed animations to make it work. Then it records it with ffmpeg and saves the output as the final video.

About 6 months ago I spent 12 hours creating a video for our Edge.js [1] announcement that, in the end... people were not very inspired by (to say the least). See the video here [2].

Then, about a month ago, I spent 6 hours creating a video for our Wasmer SDK announcement. It was better, but still didn't go as viral as I wanted [3]. I always thought we would need a big budget to do them.

But then, yesterday I tried Opus 5.5... and man, I'm impressed. The video was one-shotted with this prompt:

    Make a modern slick and punchy video for this announcement:
    [content of the blogpost in markdown]

This is what Claude Opus 5.5 one-shotted (tl;dr: we went viral): https://x.com/wasmerio/status/2102849543260029379

[1] https://edgejs.org/

[2] https://x.com/wasmerio/status/2033966082944577693

[3] https://x.com/wasmerio/status/2094845905379922302

> I think the word you want is "eager".

Yup, thanks for the correction! (and appreciate the extra insight!)

I think this showcases the other issue I commented a few years ago [1].

Pyodide and Cloudflare don't use the real network stack for http requests (they patched the functions to use JS `fetch` underneath). They also patched Python's async event loop to use JS event loop.

This has a major downside: incompatibility issues. JS event loop is preemptive (async functions get called regardless of you calling await on them) while Python is lazy (async functions only execute when you await them).

In my belief, the network semantics should be preserved. When the behavior differs issues start arising.

[1] https://news.ycombinator.com/item?id=39907240

Thanks for chiming in!

> it is worth noting that by using those older versions you will also be using older Pyodide versions too

Yeah, I think this summarizes properly the issue I mentioned. Basically compat flags are a global version that affects not only the Python version used but workerd as well. I believe you'll see some architectural issues from this design. Following up on your example, users will not be able to use a previous version of Python that has JSPI included, unless you update the old workerd as well (please correct me if I'm wrong), which will make certain things a challenge as workerd evolves.

> We wrote about cold starts (and sharding) in a previous blog post[2] which includes some numbers

Thanks for sharing. On that blogpost [2] Cloudflare Python Workers startup time was reported to be about 1.027 seconds, which is way behind the numbers we have at Wasmer for cold starts in Python apps (60ms, or 16x faster). That's why I was asking if you guys remeasured and have better timings now :)

Great work from the Cloudflare team!

I was very excited when they first launched Python Workers two years ago. Even though we have competing products at Wasmer, I think Cloudflare work is always exciting and inspiring.

I went back to the feedback I posted in the original launch thread [1]. It's great to see that they have made meaningful progress since then, particularly around package support: PyEmscripten is now standardized through PEP 783.

That said, some of the main architectural concerns I raised at the time are still present:

  * Being tied to use only one version of Python/Pyodide (the one that Workerd embeds)
  * Architecturally tied to the JS/v8 world, which may show some challenges as they aim to reduce cold start times (in my opinion, it will be quite hard for them to achieve <100ms startup time with their current architecture).

In the benchmark we published earlier this year [2], a minimal Python application started in around 60ms on Wasmer Edge versus around 900ms on Cloudflare Workers (backing my concerns from 2024). Those numbers are now several months old, and I hope Cloudflare has improved them significantly since then.

The GA announcement doesn't seem to include updated cold-start numbers. Could someone from the Cloudflare team share the current p50/p95 cold-start times for Python Workers, ideally both with and without native user packages? (for example, one with FastAPI and other without any dependencies).

[1] https://news.ycombinator.com/item?id=39907120

[2] https://wasmer.io/posts/wasm-clouds-the-world-after-containe...

This is incredibly impressive. Great work!

We will launch very soon the Wasmer SDK with support for mobile (androids and iOS)

Wait to see what Wasmer has in store... :P

ahahaha

It's refreshing to see more self-made JS runtimes.

I'd love to see if I can integrate it onto Edge.js for full Node.js support ( https://edgejs.org )

Fixed!

Yeah, we create Wasm Containers from your application and deploy it to the edge so it can scale serverlessly :)

Excited on what this brings to the server-side :)

We have created Edge.js that can run Node.js apps fully using your preferred JS runtime: V8 or QuickJS.

https://edgejs.org/

If you are looking for a Systems Interface, I don't think the Component Model will be a good fit

Congrats on the release to the WASI team.

TL;DR: WASI 0.3.0 is the Component Model-based WASI proposal. It adds async/await-style capabilities such as actors and streams, and today is runnable in only one server-side Wasm runtime (it is not supported natively by browsers). Unfortunately it still breaks compatibility with the original WASI proposal and runtimes that supported it.

If your goal is to compile existing, unmodified C/C++ programs and libraries to WebAssembly, WASIX may be a more practical option today ( https://wasix.org/ ). Disclosure: I’m part of Wasmer, the company behind WASIX.

This is a fork of Chicory, a bit more context of the relationship between the projects can be found here:

https://github.com/dylibso/chicory/issues/1296

It's great to see that since the release of Edge.js [1], they started to take Node.js compatibility more seriously (they went from ~40% to about 75% in just 2 months, so either coincidental or not this is clearly a step on the right direction).

Good work to everyone on the Deno team!

[1] https://edgejs.org/

Yeah, the strategy is literally the same

Wasmer (YC S19) | https://wasmer.io/ | Multiple Roles | Remote (EU) or Office (US) | Full-time

We are building the next generation of infrastructure for AI without Docker containers, but with a better container technology based on WebAssembly!

We are hiring for:

  * Rust Engineer (Remote, EU timezone)
  * Rust Distributed Engineer (Remote, EU timezone)
  * Developer Education Engineer (Office, San Francisco)

https://www.workatastartup.com/companies/wasmer

Well, with the help of AI now you can have Fast, Affordable, and Correct.

Just set it to MIT :)

Thanks Yuri. Keep up the good work

Actually agree with you here. It will be a good idea to add docs for the CLI and the WebAssembly sandboxing

Yet... stay tuned!

Thanks Ben! Took us a bit to figure out the best architecture for it, but once it became clear then it was just a matter of implementing the missing bits.

I think the fact that WASIX is much more mature now have helped to increase development speeds quite a bit!