lumen VS lunatic

The BEAM (runtime?) is written in C. There is also an effort to rewrite it in Rust (https://github.com/lumen/lumen). Some functions are built into the VM but most of the supporting 'standard library' (OTP / Open Telecom Platform) is written in Erlang. The (main) compiler is written in C. So it's all C or Erlang afaik.

It is ported to every major flavour of OS.

I don't know what 'back end' means in this context.

There are attempts to implement an Erlang/BEAM-inspired reactor/runtime/executor/ecosystem for Rust's Async, in particular Bastion. (There are also Lumen, Lunatic and Async-Backplane/Async-Supervisor.)

If I recall correctly, Saša Jurić mentioned in an interview that he envisions the BEAM being used as an OS in the future, where you can run your database, web server and other services under one VM.

While I don't personally have much use for it (at the moment), I'm curious about how this would look like with Lumen [0] where you can run your whole web stack with a single binary and being internally supervised by the BEAM.

Lumen's development has been slow but I remember seeing a tweet from a team member stating that development is slowly ramping back up (not a criticism in any way, just providing some context).

[0] https://github.com/lumen/lumen

If you can't find a way forward, you could always peek here: https://github.com/lumen/lumen

Lumen: Alternative BEAM implementation, designed for WebAssembly\ (11 comments)

Any thoughts about making Lunatic embeddable? I saw this [issue](https://github.com/lunatic-solutions/lunatic/issues/10) earlier, and am curious what obstacles are in the way (would be willing to help)!

Webassembly is also gaining steam for server workloads due to several advantages (less overhead, better capability based security, composability, ...).

See Spin [1], Wasmcloud [2], Lunatic [3], etc.

My system is based on a distributed Webassembly runtime.

The reason for taking inspiration from Kubernetes is making deployment of distributed workloads on that runtime easy.

A nice benefit for a Kubernetes alike system is that the equivalent to controllers can be much more light-weight WASM actors that are easier to deploy and scale.

[1] https://github.com/fermyon/spin

[2] https://github.com/wasmCloud/wasmCloud

[3] https://github.com/lunatic-solutions/lunatic

I'm the author of a Wasm on the server side runtime[0] that focuses primarily on rust compiled to Wasm, and this question comes up quite often. Why compile to Wasm if you can compile to native code directly? To add to Radu's answer, here are some of my favourite reasons.

Having an in-between bytecode layer allows you to build application architectures in rust that would not be possible when compiling directly to machine code. Hot reloading is a good example. Having the VM hold onto resources like tcp streams and file descriptors allows you to exchange the business logic without even breaking a tcp connection. Fine-grained sandboxing is another good example. Revoking filesystem access from just parts of your applications or limiting memory/cpu usage for each individual request[1] is something that is just impossible to do correctly without a vm managing it.

A less obvious benefit are the improvements to the developer experience, like compile times. Most of the dependencies (async executor, tcp stack, message passing, ...) are usually already part of the wasm runtime and don't need to be compiled/linked again. The rust compiler also seems to have a better time when it comes to generating .wasm executables instead of native ones. Most rust wasm apps I write compile much faster than equivalent native ones. Just because there is so much less for the compiler to do.

Many wasm runtimes, like lunatic, include an async scheduler and green threads/processes. This means that you get most of the benefits of async rust without needing to actually use async and worry about all the issues that come with it[2].

[0]: https://github.com/lunatic-solutions/lunatic

[1]: https://www.youtube.com/watch?v=8gwSU3oaMV8&list=PLdo4fOcmZ0...

[2]: https://eta.st/2021/03/08/async-rust-2.html

Here is an example of a pretty feature heavy solution: https://github.com/lunatic-solutions/lunatic It uses MsgPack to communicate between processes.

There are attempts to implement an Erlang/BEAM-inspired reactor/runtime/executor/ecosystem for Rust's Async, in particular Bastion. (There are also Lumen, Lunatic and Async-Backplane/Async-Supervisor.)

People interested in Erlang-like fault tolerance combined with C++-like speed should take a look at lunatic.

I just pushed out a new release of lunatic with support for running distributed lunatic instances. You can check out the release notes here.

It's on the embedder (Wasm VM) to provide this functionality. I'm working on a Wasm runtime [0] that is written in Rust and uses stack switching to allow you to call Rust async functions as if they were blocking. This keeps the Wasm bytecode simple (blocking), but at the same time provides high performance i/o.

There is also a proposal to bring stack switching to the browser.

[0]: https://github.com/lunatic-solutions/lunatic