search

sagemathinc / cowasm

CoWasm: Collaborative WebAssembly for Servers and Browsers. Built using Zig. Supports Python with extension modules, including numpy.
https://cowasm.org
BSD 3-Clause "New" or "Revised" License
482 stars 23 forks source link

support bun as an alternative to nodejs for the server runtime environment #19

Closed williamstein closed 1 year ago

williamstein commented 1 year ago

Currently we use node.js for tooling and running python-wasm on the command line.

However, there is a new project https://bun.sh/ that is similar to Node.js, but written using Zig instead of C/C++. Since (1) we're also using Zig and typescript extensively for python-wasm, and (2) bun is very fast and modern with native typescript support, it would be natural to use bun for python-wasm, at least optionally. It might me faster startup times, faster execution, etc., and also easier to read code if we want to dive into the runtime itself. A blocker prerequisite for this is WebWorker support, which bun.sh does NOT have. It's on the roadmap here:

https://github.com/oven-sh/bun/issues/159

williamstein commented 1 year ago

WebWorker support might not be a blocker at all. I can instead write a native extension module and use that to get input from stdin. I don't see any reason why that wouldn't work...

williamstein commented 1 year ago

WebWorker support is definitely not a blocker, though of course there will be limitations (only a single webassembly process can possibly run at once for subprocess.Popen). Regarding the native extension module, it looks like I should instead have a version of our posix-node package that instead is written using Bun FFI, which fully supports using Zig.

williamstein commented 1 year ago

Here's the webworker thread: https://github.com/nodejs/node/issues/43583

Also, it would be interesting to see how's bun's event loop, etc., deals with just forking/execing via bun ffi (and stopping it). Maybe it behaves differently than node.js, which randomly crashes!? If os, we might not need webworkers for our use case, and can rewrite to use them later when they are implemented.

williamstein commented 1 year ago

The first step would be to port the debug package

https://www.npmjs.com/package/debug

to work with bun, since we use it everywhere and it is very helpful with debugging. Currently it doesn't import because process.stderr doesn't exist with bun, but it is assumed to exist by debug.

williamstein commented 1 year ago

I may revisit this in a year or so, but for now the focus will be 100% on node.js, due to wide support and integration with electron.js, and no compelling advantage for cowasm to use something else.