Hacker News Reader

Comment by sodapopcan | Hacker News Reader

> Rails is going to be a better pick in some circumstances because of the huge number of libraries.

This isn't really as big a problem as many people think. I've been out of Rails for a while now but haven't really felt the pain of missing anything with Phoenix. I've noticed there aren't often Elixir wrappers around third party APIs, but those are really not a big deal to create a small version on your own with only what you need. I always used to wrap the wrappers anyway! As far as UI stuff goes, there are actually a lot of really nice vanilla JS libs out there which play really nicely with LiveView's JS hooks.

I would be interested to hear what people have been sorely missing, though.

EDIT: Said "are" when I meant "aren't"

View on HN

Oh, I don't think the library thing and ecosystem is really an obstacle for using Elixir so much as it makes Rails a 'safe bet'.

If I'm putting on my business hat, I need a reason to use Elixir instead of Rails and that probably has something to do with a better concurrency story, but I'm always curious to hear what other people are getting out of it.

My previous experience with BEAM was using Erlang in a semi-embedded environment and it was fantastic for that. Solid, dependable, deterministic, great response times... all of that. But while we did have a web interface to the system, it wasn't a web site.

For us its the simplified production environment. We use BEAM's clustering capability to forgo things like redis and/or a message queue. It probably doesn't matter for every company, but it helps for us where we have zero full time ops people.

That's a pretty good reason. Some people might react "well, you're going to need those things broken out anyway as you scale" or something to that effect, but it can be really nice to just not need them until you have scaled further. There are plenty of smaller applications where you just don't want or need all the extras and the longer you can keep it simpler, the better off you are.

Ya, this is one big bonus in my eyes. I have certainly hear the argument several times that "installing redis is really easy" and it is! But it's another moving part that often isn't necessary with BEAM.

In a current project I'm also able to use OTP to create a single microservice for my monolith that runs on its own node and the two can communicate with run-of-the-mill message passing without the need for an HTTP API.

> Some people might react "well, you're going to need those things broken out anyway as you scale" or something to that effect, but it can be really nice to just not need them until you have scaled further.

Dist messaging and mnesia scale pretty far. Although it must be noted that they were original built around rock solid networking (two nodes in one chasis), so if your networking is flakey, you have to handle that; my recommendation is to make your network not flakey, but that's easier to say than it is to do.

I would pair BEAM with Postgres, not Mnesia as that's going to limit you in a lot of ways. Unless you reaaaaaally know what you're doing.

Well, I like to think I know what I'm doing. And I've participated in some big Mnesia operations.

That said, redis is in memory key-value, and Mnesia does in memory key-value too. If you're using Postgres's relational stuff or data bigger than memory, that's a different thing. Mnesia has some relational facilities, but I dunno if anybody uses them much; mnesia can use disc_only_copies, but that's not a good time. Of course, memory only gets you pretty big tables these days; I ran some mnesia nodes with 768GB, but a couple TB isn't too hard to put together these days.

The BEAM's multi-node scaling works really well. The argument that you'll need to break things out if you get big enough doesn't really hold water.

And even if you need to break things out, you can build different variants of distributions that can all still work together.

BEAM isn't magic scaling sauce, and you're going to run into trouble if you get big enough. But that's a "good problem to have". And it's probably 'enough' for many businesses as-is.

It's not magic, but neither are any of the alternatives. There needs to be a compelling "my constellation of services written in a variety of languages, communicating via a half-baked homebrew collection of API calls beats a constellation of distributed Erlang applications communicating via message passing over the BEAM" to claim that Erlang has scaling issues relative to the alternative.

The reality is that asynchronous, parallel, distributed computing is hard, Erlang makes it easier. Not easy, but easier.

And if you forgo those things you can easily test them.

My reason to use Phoenix instead of Rails: development speed. I'm just so blazingly productive in Phoenix that nothing else compares, including Rails. Every time I'm forced to develop in another framework I now get agonisingly frustrated by how long it takes to get anything done.

Your experience matches mine. And ChatGPT has been a game-changer - if there isn't an Elixir library for some third-party API, GPT is very good at generating some wrapper functions in Elixir using the API docs.

Reply on news.ycombinator.com