Hacker News Reader

Comment by davidw | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com