Re:How we got to LiveView
by 0x000000001 on Thursday September 23, 2021 @10:55AM
(#28630064)
It prevents unnecessarily moving data around. And if you're running the whole stack on the same server with Sideqik you're dealing with interrupts and memory copies between processes; in Elixir it's all within the same allocated memory and nothing gets copied. Plus it's another service you don't have to monitor because it's automatically monitored by BEAM.
[ Parent
| on HN ]
Re:How we got to LiveView
by joelbluminator on Thursday September 23, 2021 @11:42AM
(#28630800)
What if you want to scale your job workers and your servers separately?
Re:How we got to LiveView
by 0x000000001 on Thursday September 23, 2021 @03:20PM
(#28633928)
Oban will let you choose which servers the jobs can execute on, and you could do the same with your own app code
> Queue Control — Queues can be started, stopped, paused, resumed and scaled independently at runtime locally or across all running nodes (even in environments like Heroku, without distributed Erlang).
I think it's nice that you can run everything in the same server. If you're scaling, and want to split everything up, that's a "nice problem to have", but it's convenient if you can just run everything in the same application/codebase when you're getting started.
I do agree with you that's not a huge win compared with Rails, but it is nice to have. I think you'd have to look more at something like "lots of concurrent, long-lived connections" for the real wins over Rails for the BEAM ecosystem. I mean, you can do that in Ruby if you want to, but it's going to be cleaner and simpler with Elixir/Erlang.