[dhab]

My limited understanding of erlang/elixir is that it helps easily run actor model programs (fail-safe loosely defined as something with retries built-in) in a grid of long-running interconnected instances. With more and more focus on "serverless" development that I am being exposed to, I am curious to know if it is a good fit in this space. Say if you are constrained to use AWS serverless solutions - sqs, sns, dynamodb, lambda, cognito, api-gateway ... etc, with event-sourcing (for event-drivenness) with retries (automatic/configurable), (why) would using erlang/elixir vs say nodejs/typescript/go/haskell/java be a good choice (let's assume you equally love these languages for the sake of not getting in to 'but X is better than lang Y')?

[busterarm]

From my perspective, I see it as a different way of achieving the same end goal. With "serverless", someone still has to maintain servers somewhere and if your company is big enough, AWS is actually the more expensive option.

So if you are running your own infrastructure on bare metal, application development in erlang/elixir lets you better take advantage of the operations staff that you already have because running that infrastructure is much less complicated than the alternatives.

[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.

[eeZah7Ux]

No. Kubernetes & friends implement most of the features of Erlang in a language-independent manner.