[jherdman]

> But I still needed background jobs, real-time updates, and two-way communication that just works. Those things are possible in Rails and Laravel, but they take a bit more effort to set up.

I'm pretty sure this isn't true at all with Rails. Out of the box you get Solid Queue (jobs), and Solid Cable (real time messaging).

[nop_slide]

Yeah def odd, I'm a recent rails convert and SolidQueue is dead simple and is setup out of the box.

When paired with https://github.com/akodkod/solid-queue-dashboard you get a nice overview.

[jamiecurle]

I think what the blog post is getting is OTP and the mystical/but not mystical GenServer / Supervisor/ distributed pattern. It's baked right in there as a core part of the Erlang VM. I think the post glances over the fact that in rails land solid queue may be right there to use (I've not really used rails in over 10 years).

Thing is with Elixir though, yes the tools are right there, but you do have to take time to understand them. I've been on and off with Elixir since 2016 and I'm currently wrapping up on a fairly complex elixir project with zero UI. (connecting Shopify GraphQL to a series of 3rd party fulfilment providers who use SFTP (gross). So yes, GenServer, Supervisor etc are all right there as first class citizens, but whilst they are relatively simple to start using, you can end up with some horrifically structured code that would have been much better written without the distributed stuff.

Personally, I prefer Django. Been using it since 2006 and as a person who started off in design but ended up as an engineer, nothing beats Django's template engine (braces for incoming). Django isn't perfect but nothing is. When I have to get something done quick and there's UI work for me to do, I go to Django. When performance or no UI, I go elixir. If someone else is doing the UI, I go phoenix.

[akarshc]

All the things are possible in rails as well. it is a beautiful framework, but it is so much easier to use with phoenix. Do try it out

[sergiotapia]

Take it from someone that uses both systems in production, they are not equivalent. Oban is leagues easier to use and obvious than Solid Queue. Solid Queue has no easy way to rerun a successful job, in Oban you can just update some dumb table columns and done, the Oban supervisor will sniff it out and workworkwork.

Solid Queue has a ton of database tables. Oban has `oban_jobs` and `oban_peers`. Oban just runs, simple on the same app. Solid Queue you can do that but it requires reading a lot of obscure blog posts and changing the settings. No sane defaults.

Just as a whole the Erlang and Elixir primitives allow oban to be built truly in the most retarded, obvious way and get away with it. It's wonderful to use as a dev.

Solid Queue I'm bearing because I get other stuff I need from Rails.

[sorentwo]

> Just as a whole the Erlang and Elixir primitives allow oban to be built truly in the most retarded, obvious way and get away with it.

Maybe it is obvious in retrospect…

[JamesSwift]

> Solid Queue I'm bearing because I get other stuff I need from Rails.

I mean sidekiq is tried and true

[tvink]

Solid cable is quite a bit of setup though,compared to Liveview. The way LiveView manages the rendering for your is leaps ahead of how actual rails SolidCable development feels.