5 ms·

it is very hard for other languages to pull this off as Erlang OTP uses a shared nothing architecture each green thread has it own GC communication is only v

it is very hard for other languages to pull this off as Erlang OTP uses a shared nothing architecture each green thread has it own GC communication is only via message passing it is ok to fail over as the threads are easy to replicate as they are cheap it is possible Golang via ergo as golang gets concurrency right, but doesnt have evolution systems and BEAM Haskell via cloud haskell might replicate live view... but they are not the sensible defaults as in erlang/elixir/otp Python never as their async concurrency parallelism story is ill-thought out w GIL limitations. Rust very very hard as their async concurrency design is extremely complex...

lopatin 4y ago
I've never used LiveView. Why is an asynchronous programming model required to pull it off?
- pmarreck 4y ago
  all client state is replicated server-side. that means spinning up and down completely isolated threads very quickly. only a stack with immutability to the core and VERY efficient processes (such as OTP threads) can guarantee this while also providing nearly instantaneous spawning from any state (thanks to immutable data structures). Every client that has a page open to your site has a tiny thread running in OTP (it does not use OS-level threads). No other popular language can pull this off.
- tylerchurch 4y ago
  It's all about a persistent connection between the client and server, with the server pushing updates to the client as new data/events come in. If you don't have a good async model, you're down to a thread/process per connection, which can get very expensive since you will have a thread for every user on your site. You need something like Erlang's lightweight internal "processes", golang's coroutines, or maybe even Node.js evented I/O async model to handle this well.
noloblo 4y ago
But you never know with rustaceans as there is a strong enduring culture to rewrite in rust

lopatin 4y ago

I've never used LiveView. Why is an asynchronous programming model required to pull it off?

pmarreck 4y ago
all client state is replicated server-side. that means spinning up and down completely isolated threads very quickly. only a stack with immutability to the core and VERY efficient processes (such as OTP threads) can guarantee this while also providing nearly instantaneous spawning from any state (thanks to immutable data structures). Every client that has a page open to your site has a tiny thread running in OTP (it does not use OS-level threads). No other popular language can pull this off.
tylerchurch 4y ago
It's all about a persistent connection between the client and server, with the server pushing updates to the client as new data/events come in. If you don't have a good async model, you're down to a thread/process per connection, which can get very expensive since you will have a thread for every user on your site. You need something like Erlang's lightweight internal "processes", golang's coroutines, or maybe even Node.js evented I/O async model to handle this well.

noloblo 4y ago

But you never know with rustaceans as there is a strong enduring culture to rewrite in rust