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.

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 even if you need to break things out, you can build different variants of distributions that can all still work together.

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