[mikece]

Does cloud-based serverless computing compete with or complement Erland/Elixir? As a dotNetCore developer who writes a lot of Lambda and Azure function code I am trying to understand how OTP relates to these paradigms or if they are apples and oranges.

[bicx]

It's apples and oranges.

OTP paradigms are definitely intended for a larger system that needs its own distribution schemes, handles its own internal process uptime and restarts, and for some use cases, hot code updates (running servers that update without restarting). OTP nodes can also easily and natively communicate between each other across the network, allowing for some pretty sophisticated distributed systems.

There are many solutions that could be more easily implemented on some sort of serverless architecture, but in cases where you want to maintain a service with a high degree of reliability and distributed capability, OTP is a good choice. After all, it was developed for the telecom industry to handle phone system communications loads.

Worth noting: there are other solutions (some of which are already in serverless environments) that solve the same problems of service uptime during code updates/deployment by keeping an older instance running until the new instance is ready to accept traffic. Services like Kubernetes also implement a lot of cluster management capabilities that solve the same problems OTP was attempting to solve, and you can use whatever language and engine/framework you want. Personally, I think if you wrote a service purely in Erlang/Elixir and directly applied all OTP solutions for uptime, process communication, and distribution, it would be faster and more efficient than a typical serverless or container-based system. But, it would also lock you into that system and make any non-OTP tech more difficult to integrate.

[macintux]

I’ve been out of the Erlang world for a few years now, but it doesn’t seem like a great fit for serverless. The VM has a non-trivial overhead, and the language (and VM) design is optimized for long-running, high availability services.

[micmus]

I would say it's mostly that nobody optimized it (perhaps yet) for that environment. There's generally nothing inherently slow in the VM boot sequence - it's just that this was not a priority, so it's slow. There are some attributes suggesting it could be a good fit for that environment, for example, the VM is generally very small - you can get a full system in ~20MB - and that again wasn't something that was heavily optimized.

[anthony_doan]

There was Erlang on Xen using LingVM awhile back.

[te_chris]

The VM has an overhead, but looking at our kube cluster right now which runs elixir and ruby pods (treating elixir as shared nothing, old school stateless, rather than distributed), mean RAM for our ruby pods is 1GB, Ex ones are 200MB. Response times: Ex: ~30ms, Ruby: ~150ms.

[lawik]

Sounds about right. With wasm being relevant for edge computing and serverless I'm keeping a close eye on the Lumen project compiler as I expect that to be more feasible for this sort of work. The advantages for OTP remain mostly in long-running services. But for Lumen that might be a more open question.

[h91wka]

Erlang VM startup time is not great (in order of hundred milliseconds), but it has pretty unique features like hot bytecode patching in a running VM. So, naturally, Erlang shines when you need to build a system that runs for a long time, as opposed to short-lived lambdas.

[voganmother42]

reminds me of: https://github.com/cloudozer/ling

[brudgers]

Erlang is a message passing language for writing concurrent applications. Architecturally, Erlang programs share logical similarity with microservices. Architecturally, OTP shares some conceptual similarity with serverless frameworks.

Together, Erlang and OTP provide a batteries included environment for building and running scalable concurrent systems. Scalable down to any device that will run Linux, not just up into the cloud.

[ex_amazon_sde]

It competes, mostly. Amazon's internal SOA implements pretty much the same principle around resilience and load balancing.

Unlike OTP it must be language-agnostic and also aware of latency and bandwidth.