News for hackers. Stuff that matters.
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.
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:

https://getoban.pro