One thing that drew me to Rust was actually Elixir/Erlang calling out to it for certain specialized needs. Within Elixir/Erlang you get best of breed concurrency but exiting the BEAM to run other code is unsafe. Calling out to Rust, however, comes with great safety guarantees.
Managing concurrency outside of Rust and then calling Rust for the more focused and specialized work is a good combination IMO.
> 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 processes are completely isolated, with a per-process stack and heap. If a process crashes, it won't affect others in the runtime.
I don't understand. Is each Lunatic process an OS process or not? If it is, it sounds anything but lightweight. If it is not, it is not "completely isolated", at least not in the usual sense of the word.
> If it is not, it is not "completely isolated", at least not in the usual sense of the word.
Well that's where lunatic comes in. Lunatic provides the isolation and abstraction so you can run various wasm binaries side by side. If one of those binaries segfaults, lunatic presumably catches the interrupt and kills the corresponding wasm instance that caused it rather than just giving up and crashing.
I was rather referring to security boundaries – if lunatic processes run inside the same OS-level process, the sandboxing cannot, almost by definition, be as good.
Why not? But you’re probably right. Anyway I doubt this os a full blown hypervisor yet. Probably more an application deployment model where you trust everything you deploy, similar to K8s.
Because if there is a vulnerability in Lunatic, one Lunatic process could (in theory) gain access to another Lunatic process's data. Kernel-space processes protect against that through various mechanisms and their implementation has been battle-tested over decades.
The kernel has vulns all the time. It’s super complicated and complex and C—that’s the real problem. Lunatic is new and simple. I wouldn’t be surprised at all if Lunatic was more secure than the kernel.
Completely isolated is probably wrong but isolated hits the nail on the head in the sense that there are no surprise global variables like in say Java.
Managing concurrency outside of Rust and then calling Rust for the more focused and specialized work is a good combination IMO.
https://github.com/rusterlium/rustler