ractor VS Ractor

This project also appears interesting, but it seems that its clustering features have yet to be tested in large scale distributed systems.

https://github.com/slawlor/ractor/discussions/131

If you look at my comment history, you'll see I'm well familiar with the BEAM.

I'm in full agreement with you, but I'm not sure you need full robust process supervision trees to mimic what the BEAM does in the context of LiveView on a single machine.

I do want to say, I 100000% times prefer Elixir, it's tooling, ecosystem, web frameworks, easy of scaling vertically and horizontally, etc over Go or any other lang that probably do something analogous to LiveView via what ever concurrency primitives that language/runtime champions; Go with it's Communicating sequential processes(CSP) and Rust with the Ractor lib (https://github.com/slawlor/ractor).

Also consider an actor framework like ractor. You can have actors listening to sockets, who will then message subscribed actor or actors with the data.

github

When I was looking for a name for my now-archived distributed actors system based on Redis ( https://github.com/buybackoff/Ractor), the choice for Redis+Actor was between Reactor, Redactor and Ractor. Then I found a reference to The Diamond Age book (https://en.m.wikipedia.org/wiki/The_Diamond_Age) where a ractor is a live human performer working from a computer-provided script. I found it somewhat fitting to the actors abstraction. And the most cyberpunky.