libcluster VS lumen

libcluster is the go-to package for connecting multiple BEAM instances and setting up healing strategies. libcluster provides out-of-the-box strategies and it allows users to define their own strategies by implementing a simple behavior that defines cluster formation and healing according to the supporting service you want to use.

I am using libcluster to connect my nodesI get the following error:

Distributed Elixir can be done with Docker containers too, see https://github.com/bitwalker/libcluster which by default has some Kubernetes support but you can also have third party (or custom) clustering strategies. I've not done this myself but I've seen articles about this a lot during the past years.

Hot code updates for most applications aren't really worth it in my opinion, assuming you do something like blue/green rollover deployments. It's cool that it's possible though. But it requires appup files and afaik Distillery is one of the release tools that has support for it built-in.

On the deployment level, you can use synchronous communication using API-based solutions or asynchronous communication using external solutions (RabbitMQ, Kafka,...) or Erlang/Elixir tools (message passing, pg2, PubSub, Libcluster,...)

Looking throught libcluster code (https://github.com/bitwalker/libcluster/blob/master/lib/strategy/kubernetes_dns.ex#L150) it does seem to require that both nodes share the same basename.

libcluster – Automatic cluster formation/healing for Elixir applications.

There are details on this also: https://github.com/GetFirefly/firefly#runtime

Generally it should be assumed that actors and their concurrency model is fully supported as that is a part of the core semantics for BEAM languages.

I think this project used to be called Lumen until pretty recently - https://github.com/GetFirefly/firefly

Probably not a practical solution for what you are building now, but it's worth pointing out Lumen, an Erlang VM implementation that compiles to WebAssembly, and could one day enable Elixir on the frontend.

Another vector could be some tooling that makes it easy to run Go programs compiled to Wasm run inside of Wasmtime environment hosted in Rust. If we run the go tooling in the same system, one could point this tool at a Go repo and be running that Go in a matter of milliseconds. A fun feature would be running channels across separate Wasm envs. Or maybe use Lumen.

Wish the Elixir WASM project -- Lumen -- were active. It seems like nothing much is happening on it.