lumen VS embly

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)

Hey, I tried to build something like this too: https://github.com/embly/embly

My takeaway after building that is that the build tooling is the major pain point. If you're trying to onboard someone onto this platform from their favorite language the hard part is getting from code to the .wasm file. wasm-bindgen (as an example) has put so much effort into build tooling, I wonder if that's a necessary path for success here.

It's also great that WASI exists now, if I had to do embly again I'd just use wasi and then implement all of my "platform" features as filesystem features, not syscalls. If your API interface is the filesystem then you could provide interoperability between environments. Let's say you want to include a key-value store in the wasi runtime, you just make the keys files and the values file contents. Then you could so something like ship a FUSE filesystem to interact with the filesystem in the same way from a traditional VM or on a personal computer. I got really bogged down in custom syscalls and this path seems potentially more elegant.

Have you also thought about live process migration? I got really excited about this from a technical standpoint. Since you completely control the runtime you could set up a clustered wasm solution that moves long running processes from VM to VM by sending their live memory state to another machine. Not sure if that's actually useful, but cool that it's not bogged down by the usual complexities of doing the same in a full OS environment.

Anyway, so glad to see that someone is taking this idea on. Please make a cloud platform and let me pay for it. Also happy to chat more if any of this is useful, I've joined your discord as "max".