Comment by grncdr | Hacker News Reader

Comment by grncdr | Hacker News Reader

Parent Full thread

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.

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

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.

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.

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

What is presence awareness?

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.

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.

Reply on news.ycombinator.com