[lotyrin]

The modern serverless paradigm is a way to give these more traditional computing runtimes/languages a lot of the features of Erlang/OTP.

The downside to having all of these things in services on the network and outside of the runtime is latency. Imagine a runtime where everything is a message, everything goes into inboxes/queues but passing many of those messages is zero-copy, doesn't hit a network interface, and going from the calling code to the called code isn't even a OS level context switch -- so the message is written to and read from a core/thread's local cache lines.

[rkangel]

To me, the bigger downside is system complexity. If everything is an BEAM process, then testing, debugging and generally understanding is much easier. Things like spinning up a dev 'deployment' become trivial and things are going to behave in production as I expect them to.

[dhab]

For fault-tolerance in case the box is unresponsive for whatever reason, I think you would have to have a network behind a load balancer. So the issue of network latency still exists, but probably to a lesser extent?

[lotyrin]

Yes, obviously some things will need to be persisted, and some of those things might be some of your queue entries -- so a persisted network queue (and network things to dequeue from it) can definitely be a necessity for that reason as well.