By combining the fault-tolerance and massive concurrency of Erlang with the capability-based security of WebAssembly, it creates a powerful programming model.
Lunatic is a single executable and runs on Windows, macOS and Linux. It spawns lightweight processes from WebAssembly modules that have their own heap/stack. These processes are preemptively scheduled on a multi-threaded executor.
Lunatic’s design is all about super lightweight processes. Processes are fast to create, have a small memory footprint and a low scheduling overhead. They are designed for massive concurrency.
Lunatic sits between your operating system and the running processes. This allows it to decide on a per process basis what syscalls are going to be forwarded to the operating systems.
If you would like to run some untrusted code, you can. Just spawn it inside of a process without any privileges.
This looks pretty interesting and I’ve not fully got my head into the details yet however I think you have possibly put this into the wrong category. The first thought I got from the first few paragraphs was this was looking like something in the realm of Lumen but taking inspiration from BEAM / Erlang rather than implementing it. It seems however it is a server side thing.
From the FAQ page:
What is Lunatic?
Lunatic is a universal runtime for fast, robust, and scalable server-side applications. It’s inspired by Erlang and can be used from any language that compiles to WebAssembly.
From what I can wrap my head around this seems to be an Erlang inspired web assembly runtime environment allowing people to run web assembly modules of some kind as something similar to processes. It claims to do many of the core things like isolation, own stack/heap, inter process messaging, pre-emptive scheduling, super light processes, big concurrency… but the processes themselves execute WASM and it seems like runtime features are surfaced through libraries. I think the idea is building backends from loads of tiny WASM things that live in and talk to each other on a BEAM like runtime layer.
I think @mindriot pretty much nailed the core idea behind it.
It doesn’t need to be just “loads of tiny WASM” things, it can only be one WASM module that spawns processes from functions defined inside it. Lunatic should be usable for small projects to really big one. I love using it myself to play around with small side projects.
Lunatic can offer a bit more powerful per process isolation than you get on the BEAM. E.g:
You can spawn a process that can only use a limited amount of memory or CPU.
You can use C bindings without fear. Once everything is compiled to WebAssembly, long running code will still be preempted and crashes don’t escape the process boundary.
You can limit syscalls on a per process level, e.g. spawn this process but don’t let any code running in it open a network connection.
Redirect syscallls, e.g. if this process writes to a log file redirect the stream over the network to an Elastic cluster.
You can use it from you favourite language if it compiles to WebAssembly. Currently we only provide libraries for Rust and AssemblyScript.
A long term goal of the project is to be able to take some codebase, let’s say a C project, recompile it to WebAssembly and run it on top of Lunatic. If you use threads in your project, we abstract them with much more lightweight processes that share memory. If you do a blocking network read, we just take this thread off the executor until the data arrives. We want to bring as many benefits of Erlang to other languages with the least amount of work required from the developer and stay close to the existing APIs of each language.
If anyone has some questions, I would be happy to answer them.
One starting question from my side would be: do you have any testing harness in place that confirms that Lunatic has the runtime guarantees that the OTP has?
I am really loving Elixir and the BEAM but speed and efficiency can be a concern. If we get to a point where a Rust levels of performance runtime exists with all OTP guarantees then I’ll be an immediate convert.