Re:Ruby concurrency is hard: how I became a Ruby on Rails co...
by cpursley on Thursday November 24, 2022 @07:35AM
(#33730596)
All those things you listed required additional background servers, redis, etc. In Elixir/Erlang, it's built into the runtime which is a huge advantage. And even with standard things like handling http requests - Elixir absolutely smokes Ruby.
[ Parent
| on HN ]
Re:Ruby concurrency is hard: how I became a Ruby on Rails co...
by silasb on Thursday November 24, 2022 @09:59AM
(#33731998)
Those built-ins that you are talking about are not as well rounded as a dedicated framework. These built-ins operate at a different operating model than running additional background servers. This typically means that everyone in the org needs to be an Elixir/Erlang expert instead of having experts in Redis, cloud native, ... For better or worse, this is likely a large obstacle for many orgs.
The argument for using Elixir/Erlang is also more difficult when you have large companies like Github and Shopify demonstrating that Ruby can scale.
EDIT:
Let's not forget that it's mostly the DB that slows CRUD apps down. Not the language or the framework.
Re:Ruby concurrency is hard: how I became a Ruby on Rails co...
by grncdr on Thursday November 24, 2022 @12:30PM
(#33733901)
No, they don't. You can absolutely run ActionCable on Rails + Postgres with no additional services.
Re:Ruby concurrency is hard: how I became a Ruby on Rails co...
by cpursley on Thursday November 24, 2022 @04:06PM
(#33736232)
I'm using Quantum as my job runner in Elixir. Doesn't require even Postgres. Can't do that in Rails or other stacks:
https://github.com/quantum-elixir/quantum-core
^ obviously it won't fit every use case (where you need 100% durability) but for that there's Oban which is awesome: