That’s really cool! Have you tested it?
kelvinst
wanton7
There is Enigma VM as well. It might support WebAssembly in the future GitHub - archseer/enigma: An Erlang VM implementation in Rust · GitHub
3
msand
I haven’t tested it yet, but looks very interesting. I was looking into running multi-core logic in the browser recently, and have the emscripten pthreads examples working fine, but it requires allowing shared-array-buffer, which kind of opens up spectre / all the speculation bugs, perhaps a bit more than necessary (and it’s only available behind flags atm).
I was thinking perhaps someone would’ve used BEAM with message passing between Web Workers rather than shared memory, to get scalability without opening up bugs in the hardware architecture. But seems this hasn’t really caught on properly yet.
There was discussion about a rust rewrite in 2017 Redirecting to Google Groups
i’m happy someone is working on it at least 
0
peerreynders
Being thread-based, Web Workers are heavyweight (compared to BEAM processes) and data transfer between them isn’t particularly fast (thread hop delay 1- 15ms) - which likely explains the focus on SharedArrayBuffer.
Edit: It seems threads for WebAssembly start web workers without the overhead of 4MB for each V8 isolate for JS and share wasm modules.
Google seems to be working on developing a web standard scheduler/task processor for browsers.
See further:
So I suspect that adapting the BEAM scheduler for the browser environment is a non-trivial port and one has to wonder whether the resulting size of the WebAssembly asset may constrain its usefulness.
You need to implement a fault-tolerant, scalable, soft real-time system with requirements for high availability.
… and while concurrency is an obvious goal on the browser, I don’t think anybody is giving fault tolerant or high availability much thought or value.
For the time being WebAssembly for the browser seems to have a role that is similar to NIFs for the BEAM. So it makes sense that C, C++, and Rust are the officially supported languages, while everything else is considered (highly) experimental.
Making the browser do things, scripting the browser via the various browser APIs, is still the domain of ECMAScript.
- By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript, passing in integer and floating point primitive data types. Thus, to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call. Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this.
(There are future plans to allow WebAssembly to call Web APIs directly).
3
msand
Thanks for the links! I was also thinking of the possibility of message passing between workers more like sending messages over the network, and running beam processes inside each worker. Fault tolerance and ability to update code in runtime are interesting for some use cases I have in mind at least. And I have at least one p2p experiment I’d like to try where high-availability would be useful as well.
Rust has relatively good bindings to almost all the apis exposed by browsers now: https://rustwasm.github.io/wasm-bindgen/api/web_sys/
While things like RTCQuicTransport are obviously missing, but that can be worked around anyway, as there’s the escape hatch of calling into js and having access to all the apis from there.
At least for the kinds of experiments I’m thinking of, the size of the assets for the vm wouldn’t matter too much, as those would be updated relatively rarely and could be cached quite well.
1
richardpringle
What about running wasm modules on the beam? I think that would be useful for portability of code. For instance, it would be great if I could get the fault-tolerance guarantees of the BEAM by running a containerized version of something in the beam itself (something like SQLite for example).
1
blatyo
Conduit Core Team
When I was at CodeBEAM SF, I learned there was a group of people (not sure who), who were looking at porting the BEAM to Rust, so they could take advantage of Rust’s ability to compile to WASM. However, it sounded like it was in very early stages and there were some complexities in how the BEAM made some dynamic calls (if I remember correctly). I wouldn’t be surprised if it’s a couple years before it sees the light of day if ever.
0
blatyo
Conduit Core Team
I don’t know that it’s impossible, but I feel like it wouldn’t be very performant. I don’t think the BEAM is optimized to perform the types of operations that are necessary to run WASM code.
0