[grncdr]

I really have to disagree. My perspective is somebody that did some Rails work >10 years ago, followed the hype/money into Node.js and eventually Go, then ended up working in Rails again ~4 years ago.

In my experience a bog-standard vanilla Rails + Postgres setup provides all of the things you mentioned (except presence awareness, which is pretty tricky).

* Server push. Websockets. Push notifications. => ActionCable

* Scheduled jobs. Long running background jobs. => ActiveJob

* Calls into other services. => Pick your preferred HTTP library (or just use Net::HTTP)

All of the above have been part of Rails for years. The only additional Gem I would add is good_job to be the ActiveJob backend.

Now, if you start to bump up against what vertically scaling Postgres can handle, or you want some of the _additional features_ of a 3rd party dependencies (Redis, Sidekiq, Webpack, etc. etc.) you can easily add them, but it's realllly unnecessary for 99% of apps out there.

[cpursley]

All those things you listed require 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 in Elixir -absolutely smokes Ruby in terms of performance. This leads to real cost savings as well

[silasb]

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.

[grncdr]

No, they don't. You can absolutely run ActionCable with the postgres adapter in your main rails app server and require no additional services.

Edit: this is also why I mentioned GoodJob, it supports the full ActiveJob API (delays, retries, etc), even comes with a nice Web UI, and it only requires Postgres.

[cpursley]

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

[quickthrower2]

What is presence awareness?

[grncdr]

I will just steal the first paragraph from https://hexdocs.pm/phoenix/presence.html, but you can read much more about it there.

> Phoenix Presence is a feature which allows you to register process information on a topic and replicate it transparently across a cluster. It's a combination of both a server-side and client-side library, which makes it simple to implement. A simple use-case would be showing which users are currently online in an application.

[quickthrower2]

I see! Funny enough the app of the company I work for does this. The tech is simply running a stateful server behind the web server.