Erlang/OTP inspired actor systems that run Webassembly code are a brilliant (and potentially way superior) alternative to microservice madness.<p>Until now adopting Erlang or Akka meant restricting yourself to a single language ecosystem, but Webassembly maturing and more and more languages gaining support means that you can still use a heterogeneous ecosystem while benefiting from easy sandboxing and isolation, almost instant startup, actor snapshotting/migrations, a unified way of inter-service communication ...<p>All while avoiding the complexities of grpc, building Docker images, Kubernetes, service meshes, "serverless" frameworks, ...<p>WASM running in the browser pushes languages to adopt it. Even Microsoft is really investing into dotnet support via Blazor [5].<p>Also check out wascc [1] [2], which is similar, also written in Rust, quite a bit further along , has some very cool concepts around security and code signing, and supports multi-node systems. (not affiliated)<p>There is also a spec for distributing WASM via OCI (aka Docker) images, which is useful here. [3]<p>Some Webassembly proposals like interface types [4] will really help out in this context as well. Sadly wasm has not quite been evolving at the pace I would have hoped for since 1.0. Progress is there, but from the perspective of an enthusiastic early adopter it can seem glacially slow.<p>[1] <a href="https://wascc.dev/" rel="nofollow">https://wascc.dev/</a><p>[2] <a href="https://www.youtube.com/watch?v=vqBtoPJoQOE" rel="nofollow">https://www.youtube.com/watch?v=vqBtoPJoQOE</a><p>[3] <a href="https://github.com/solo-io/wasm-image-spec" rel="nofollow">https://github.com/solo-io/wasm-image-spec</a><p>[4] <a href="https://hacks.mozilla.org/2019/08/webassembly-interface-types/" rel="nofollow">https://hacks.mozilla.org/2019/08/webassembly-interface-type...</a><p>[5] <a href="https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor" rel="nofollow">https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor</a>
Hi! Author here. I wrote more about the motivation behind Lunatic if you are interested, check it out: <a href="https://kolobara.com/lunatic/index.html#motivation" rel="nofollow">https://kolobara.com/lunatic/index.html#motivation</a>
This is the way forward. A wasm-instance-per-actor architecture enables:<p>- Actor prioritization<p>- Actor pausing<p>- Killing actors at arbitrary points<p>- Actor serialization / migration<p>- per Actor GC (internal to them)<p>- Multiple languages<p>- Inter-actor/host protected shared memory in addition to message passing<p>Has the potential to be better than Erlang and much, much better than Go.
I have neen trying to think of a way to leverage Cloudflare's workers/durable objects as a poor man's Erlang cluster... I think this might be it!
I've been pushing away potential suitors to learn Actor-based systems, contenting myself with researching patterns to use with F# MailboxProcessor while I wait for Gleam (the proglang that is basically statically typed Erlang) to mature enough for this newbie to be able to jump in.<p>But the concept of rust-based Actor frameworks (that compile to WASM!?) is very, very tempting.
It seems I've been in my "ignore all new tech stuff" hole for too long when I open a project link and don't understand most of the value/code. It seems very interesting though, I am not knocking the project at all.<p>So, I write code that compiles to WASM, and then pass that code as a process to Lunatic? Is this pattern intended to be a generation beyond microservices/containers, where rather than writing a "service" that gets put into a container and then managed by a container orchestrator, you're creating processes that get managed by a process manager? To get rid of the container overhead? If that's true, isn't it just all turtles because Lunatic will have to run out of containers (and presumably those will have to be managed/orchestrated)?
Pretty slick, reminds me of Erlang in that Actors are just functions. I've always thought this made stateful actors a bit weird since they have to recurse. I like the wasm approach though.
I would love nothing more than for dotnet to adopt something like Erlang's actor system as well AOT compilation to native. I don't think I'd ever leave my house again.