I'm one of the creators of lunatic and it's great to see it on HN again.<p>We have been working on a Rust web framework that builds on top of lunatic, called submillisecond[0]. It's still in alpha and there is a lot to be figured out. Currently, we are attempting to build something like Phoenix LiveView[1] for it. One of the drawbacks of LiveView is that it requires a permanent connection to the backend, but because lunatic uses WebAssembly on the backend we can actually move part of the backend into the browser to allow for low-latency and offline use cases. Hopefully, you will be able to "just write" rust backend apps, but automatically get rich user experiences with offline support.<p>A big struggle for us has been the translation of some of the dynamic patterns from Erlang/Elixir to the strict type system of Rust. Also, Rust can't fully understand lunatic's processes, because the language was not designed with a concurrency model in mind where each unit of work gets their own heap memory. So there is some de/serialization going on when pushing data between processes.<p>As someone else mentioned, lunatic extends WebAssembly with a concurrency model, networking support, permission system, distributed compute, preemptive scheduling. But it's also a whole system for executing Wasm. So you can from your running wasm app load external .wasm files and spawn processes from them with specific constraints (memory/cpu usage, filesystem access, etc.). Someone in our community is building a system that uses submillisecond in combination with a dynamic router that dispatches workloads to external .wasm files. As you can probably tell, I'm super excited about all the possibilities and the future of lunatic.<p>[0]: <a href="https://crates.io/crates/submillisecond" rel="nofollow">https://crates.io/crates/submillisecond</a><p>[1]: <a href="https://github.com/phoenixframework/phoenix_live_view" rel="nofollow">https://github.com/phoenixframework/phoenix_live_view</a>
>All processes running on Lunatic are preemptively scheduled and executed by a work stealing async executor. This gives you the freedom to write simple blocking code, but the runtime is going to make sure it actually never blocks a thread if waiting on I/O.<p>I'm reading/writing a fair amount of Python and C# at the moment, and the more I see async/await in use, the less I'm convinced by it as a language feature. Whilst the guidance seems reasonable on reading (e.g. [0]), the reality is that it increasingly becomes the norm to find code where most functions/methods are declared as async, and most implementations are littered with await.<p>So Lunatic's approach resonates. There again, as an Erlang fan, I'm pre-disposed to that concurrency model. So definitely not unbiased.<p>[0]: <a href="https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/" rel="nofollow">https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...</a>
This is actually much more than a runtime. As for the actual wasm runtime, it uses wasmtime.<p>What this project provides is what WASI and webassembly in general is currently missing: all the useful stuff like TCP networking, message passing between webassembly modules, filesystem access, transparent node distribution over a network, scheduling on an executor, permission configuration per process.<p>This is a first for the webassembly space if I am not mistaken. It will probably catch people by surprise who were trying to bring similar stuff to market of wasm on the server. I'm excited to see what lunatic brings on the table!
Recently I have been working on porting a Prolog interpreter to WASI (Trealla). I’ve been searching for a way to get these kinds of useful I/O features in WASI and this looks like a great solution. Is there a C API? I’d love to take a shot at supporting it.
As someone perpetually looking through this window from the outside, my gut instinct is that I want a model that's a more pessimistic version of the Erlang model. Mostly around assuming that not all processes are good guys (more opinionated and less generous supervisor), and back pressure for mailboxes, instead of having to roll your own cooperative overlay.<p>I would not be surprised if the latter in particular introduces scalability issues due to making asymmetric communications more symmetric, but if people are having to introduce their own wheels, it may be better if the system provided it instead.
Interesting. I remember when Java just got released my friend was so excited about Java in general and it's ability to load external class at runtime in particular. He had designed distributed actor system for it. He got his masters this way.<p>A bit later there was a company that has released generic java middleware called Voyager commercially. Among the other things it offered distributed actors as well. Unfortunately for whatever reason neither was a commercial success.
Probably a stupid question, but if you are building a sandbox on the server-side, why use WebAssembly rather than something more generic? There are so many sandboxing/container/VM environments available where you can run i86/arm code directly.