Hacker News Reader

Comment by mrdoops | Hacker News Reader

Serverless systems in almost every implementation are still stateless or limited stateful-serverless (the best examples are probably Microsoft's Durable Functions or Flink's Stateful Functions - there's also solid attempts by the Akka folks).

These are largely built on top of either a stream processing (in case of Flink) or some flavor of Actor model based on event sourcing for peristence.

What I'm getting at is that you'd build a serverless system on top of Elixir/Erlang/OTP and be served well by its mature actor model implementation and excellent distribution options. See https://eigr.io/ .

The cloud provided options are interesting for some experimental / tactical use cases but I don't yet trust their abstractions to not be leaky and they typically come with vendor lock-in trade offs.

View on HN

This is one of the best answer.

Also:

- the supervisor system in Erlang/Elixir is relatively complex. It goes much beyond the "restart my service" when it crashes but allow to restart some processes, without restarting the service, and in a specific order to keep the system coherent.

- local and remote calls behave the same in Erlang/Elixir, allowing to start with a monorepo having different Erlang "apps" than run on the same node, but then running the different apps on different nodes in the future, once the application, scales. This can be done very little changes to the application.

> - local and remote calls behave the same in Erlang/Elixir, allowing to start with a monorepo having different Erlang "apps" than run on the same node, but then running the different apps on different nodes in the future, once the application, scales. This can be done very little changes to the application.

This sounds very appealing to my context.

I wouldn't really say they behave the same. They have the same interface, so it doesn't take much to send to a remote node vs the local node, but there are a lot of details in the behavior that are clearly different, as is the nature of the beast. With a local process, if you monitor it, and receive a kill signal, you know it's dead; with a remote process, you may get a process died signal or a connection died signal; if the connection died you can't know if the remote process is dead or alive. That's new behavior and can be tricky sometimes.

Ok good point. When using GenServers thought, which is most of the cases, it is mostly transparent.

Reply on news.ycombinator.com