It is not immediately clear what the intended usage pattern for Lumen and WebAssembly is.
Pros and Cons
Things we like:
The idea of having both runtime and code compile is cool
Things we’re not big fans of:
We could not immediately figure out exactly how Lumen works, and builds appear to be failing
The project might be stalled or unmaintained. It has not been updated in over a year.
WebAssembly’s goal is to be a “portable execution layer” — an OS abstraction.
If WASM becomes the standard runtime across browsers, servers, and edge networks, something still has to orchestrate thousands of concurrent tasks, message queues, supervisors, restarts, etc.
Erlang/OTP already solves that — beautifully.
So, the motivation is:
“What if BEAM’s concurrency runtime could itself be compiled to WebAssembly — and become the actor system of the WebAssembly world?”
That’s why projects like Firefly and Lumen are interesting: they’re exploring whether Erlang’s runtime model can become part of the WASM ecosystem — just like how Go and Rust shaped the serverless world.
A ten-second search reveals [0]. (Have Kids These Days forgotten all about Emscripten?) However, given that web browser pages are often short-lived, I don't see what benefit bringing in all of Erlang and its VM gets you, other than the fact that you've pulled off the stunt.
It is not immediately clear what the intended usage pattern for Lumen and WebAssembly is.
Pros and Cons
Things we like:
Things we’re not big fans of: