Erlang/OTP inspired actor systems that run Webassembly code are a brilliant (and potentially way superior) alternative to microservice madness.
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 ...
All while avoiding the complexities of grpc, building Docker images, Kubernetes, service meshes, "serverless" frameworks, ...
WASM running in the browser pushes languages to adopt it. Even Microsoft is really investing into dotnet support via Blazor [5].
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)
There is also a spec for distributing WASM via OCI (aka Docker) images, which is useful here. [3]
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.
[2] https://www.youtube.com/watch?v=vqBtoPJoQOE
[3] https://github.com/solo-io/wasm-image-spec
[4] https://hacks.mozilla.org/2019/08/webassembly-interface-type...
[5] https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
> OTP inspired actor systems that run Webassembly code are a brilliant (and potentially way superior) alternative to microservice madness
I very much agree with this. While Actor model systems have not been commonly encountered in the circles I've run in (we don't need no stinking XML Web Services, we're going to microservices wooooo), this confluence of (Actors + Rust + Wasmtime) seems perfect for the age of increasingly-parallel CPUs as Moore's Law comes in for a landing.
I hope these kinds of efforts start to represent the dawn of a beneficial trend that starts us down the curve of excitement, cargo culting, then depression, then plateau of standard utility.
This trend doesn't have to get as bad as the OO craze of the 90s, but it needs to grow large enough to get people to stop reinforcing the OO model out of baby-duck syndrome or inertia.
TIL https://en.wikipedia.org/wiki/Baby_Duck_Syndrome#Baby_duck_s...
> Until now adopting Erlang or Akka meant restricting yourself to a single language ecosystem,
"Erlang" itself is a single language, but the BEAM/OTP ecosystem isn't usable only from that language (Elixir is fairly widely used, and there are others with less-broad use).
But, even funnier is saying that about Akka: Akka is a JVM library built in Scala and usable from almost any language on the JVM (so, in addition to its "native" Scala you also have Java, Kotlin, Ruby [by way of JRuby], Clojure, and...well, listing languages with JVM implementations that could use Akka could go on virtually forever.)
I could not find any tutorial on running akka on golang, kotlinjs or scala native. I'll let you know how well it runs on python once I rewrite my whole infrastructure to use jython instead
> single language ecosystem
The BEAM supports at least 20 languages.
And you can always feel the Erlang in them (though that's not a bad thing).
All of which are tiny niche languages, except Elixir...
I actually think think BEAM gaining the ability to run WASM would be a smart development.
It would make using high performance C/C++/Rust code much easier than the NIF/Ports hassle, with much better sandboxing and scheduling control for the VM.
If they also add WASM actors on top it could expand the interest significantly.
OTP has decades of tuning and improvements that will be hard to match in other projects like this.
"Supports" and "ready for production" are two entirely different things.
I just checked, and I don't know any of them....to tell you the truth, I haven't even heared of them, except Elixir which I heared is a modern version of Erlang.
So? You probably haven't heard of 95% of the languages that has existed and exist. They're niche languages, just like the VM they run on and this doesn't mean they're half-baked like JavaScript which you've heard of.
Actually I looked at some, and they look half baked experimental languages to me. Right now I'm using Python, because PyTorch is written in Python (and C++), not because it's my favourite language. For me library support is more important than the language itself actually.
> All while avoiding the complexities of grpc, building Docker images, Kubernetes, service meshes, "serverless" frameworks,
I don't think this will happen to be honest. The WASM process still has to run somewhere, it's probably going to be wrapped up into those systems.
Also all of the code written against existing system interfaces for IO etc will not be compatible with the WASM runtime, which means you'll have to run WASM + something else too (and the easiest path is probably going to be to use those "ops" systems you mentioned).
The advantage is that you have _one_ Docker container for hosting your wasm host, and they can use some clever communications inside there, instead of having many containers which have to find each other and communicate using only basic networking primitives.
At work I have a Rust web server with basically two parts - What humans see (HTML), and what computers see (API)
The API rarely changes, and I was thinking of splitting them into two services so that I could iterate on the human side without worrying about breaking the API side.
But I don't want to do that because it means extra management overhead in Docker, extra build steps, etc. And the Docker image is unwieldy from having all of Debian packed in it.
So 1 Docker image with 2 Wasm servers in it, is less overhead (of ops) and less risk. I should still use testing to prevent the API breaking, and I still have to figure out a deterministic way to get Wasm images into the server, and measure the performance overhead of Wasm, but it's a tempting option.
I agree, I have settled on a similar principle for the small systems I build: Reduce distributed state and message passing as much as possible, use only one process if possible.
I think I have settled on a typed language using async and writing state to disk with SQLite.
The async functions give me much more context than messaging (Golang, Erlang, GRPC etc) as they preserve the function call stack, SQLite is just the "sync" part of a SQL engine so no message passing there, and types give me machine checkable interfaces.
It's going ok.
>Even Microsoft is really investing into dotnet support via Blazor [5].
I think it's kinda underestimation because Blazor seems to be one of the top "implementations" of support for WebAssembly