Seems rather quiet. from https://eigr.io/docs/history/ https://eigr.io/docs/history/ Why on the BEAM? The decision to switch technical grounds was mainly

Seems rather quiet. from https://eigr.io/docs/history/ https://eigr.io/docs/history/ Why on the BEAM? The decision to switch technical grounds was mainly guided by the fact that Cloudstate went into hibernation mode, and it made no sense to re-implement the Cloudstate proxy in Scala and use Akka Cluster itself again. Going with Go or Rust would have been an option. But we realized early on, that competing in a way with the excellent work of the Akka team we would not come soon with a replacement of all what Akka and Akka Cluster provide in the context of this project. With a modern functional language like Elixir and the Erlang Ecosystem in general in its excellent shape these days, it came to us, why not to use the BEAM, Elixir and Erlang/OTP as the technical ground for our new project. Even if Erlang or Elixir had been exotic languages to be used, the technology and especially the language in which the service proxy is written, is irrelevant in the context that enables a cloud-native and therefore polyglot serverless runtime. Eigr Functions being based on Erlang/OTP and running on the BEAM is an excellent fit for a serverless runtime to be built on. The "message in, message out" pattern for a FaaS implementation, as well as the requirements to run actually virtual actors in a distributed system is right spot on what OTP, the BEAM and Erlang are all about. I wonder if this project is still alive.