Comment by Rodeoclash | Hacker News Reader

Comment by Rodeoclash | Hacker News Reader

Parent Full thread

I've found that Elixir / Phoenix has given me the level of productivity / flexibility that Rails used to have. Perhaps it's not quite on the same level of productivity but long term maintainability seems to be easier in Phoenix, I think from the functional programming aspect / lack of magic.

Things I love about Phoenix over Rails:

- Background / periodic jobs are baked into the same runtime as the server. You can install Oban in about 5 minutes and have it generate periodic jobs without any messing around with additional Ruby processes or custom databases (i.e. Redis, although background jobs are great on Postgres these days)

- Anything real-time is given to you out of the box. Rails has ActionCable but like the background jobs above, it needs to be setup as a separate process. Livepage makes this very straight forward.

- Phoenix sacrifices some of Rails' magic for verbosity but I think that's a better trade off long term.

Things I've loved about Rails:

- The eco system.

Worked for a company that made extensive use of elixir. It was a disaster, not due to the technical stuff, but because of every other aspect of a technology choice:

- Near impossible to hire experienced people - We had to write from scratch a lot of things that are "free" with rails/django/etc - The paradigm change takes time to learn and get it right - Some people were happy to learn it, others didn't want because they knew they wouldn't use it ever again - Many missing libraries in the ecosystem. Some libraries are poorly implemented or abandoned. - Googling for problems wasn't easy, there aren't as many answers out there as you can have for Rails, Django, etc...

But yes, the Erlang VM is awesome, can't disagree with that.

I really really want to love working in Elixir and Phoenix, but I keep stumbling at the lack of database connectivity in Ecto. Anything other than Postgres seems very unsupported. When I took another look six months ago or so, there wasn't a workable SQLite Ecto3 Adapter...

I'm guessing it's just a use case mismatch.. guessing most of the Elixir/Phoenix apps being built aren't needing to integrate with existing boring backoffice stuff.

> guessing most of the Elixir/Phoenix apps being built aren't needing to integrate with existing boring

I mean... it is, but that's usually done through an API to an existing back office app. For us, we have Elixir sitting there doing orchestration, but it doesn't take over the entire responsibility of an existing app so it doesn't really make sense to rewrite or extend any part of the API into it.

Periodic jobs are one of those things that as soon as a project is a success, and has real life users, you need it.

But as you imply, rarely built in.

They've recently built it into asp.net core, but it feels unfinished, the syntax/api sucks, it's poorly documented, and unclear how to use.

Hard to get right for such a seemingly simple concept!

For me that eco system is worth so much. I find the docs in elixir so sparse, and often land on rails docs because google can't find enough to fill a page. - SO is the same, I get rails answers. Active Jobs make background tasks so insanely easy.

I find with elixir I'm adding a lot of boiler plate.

If you start scaling and running more than one instance, each instance would run the same periodic jobs. Shouldn't periodic jobs be off loaded to a queue and worker(s) to process to the messages?

With Beam, you form a cluster. It's a stateful system, so you leave only one node to do this scheduling...

The hard part for me is the lack of official SDK's. I really do not want to have to deal with the Stripe and Auth0 HTTP API's and potentially mess up Auth and/or billing. Those are not trivial things.

Reply on news.ycombinator.com