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.
The project is alive :) Last week at CodeBEAM Europe 2022 in Stockholm, we gave an update in our talk there about it and its context in todays journeys (enterprise) companies aim to move to the cloud.
http://codesync.global/conferences/code-beam-sto-2022
IIUC, this is using Elixir for the orchestration layer, but that layer is spawning processes in other programming languages, communicating with those processes over gRPC, passing state into short-lived requests in those processes, and then getting new state back in the responses. Please correct me if I'm wrong.
IMO, that approach is irreparably inefficient, because state has to be passed back and forth, rather than being stored locally over the length of a longer operation. Yes, one has to checkpoint state to be able to recover from various events, but on the happy path, it should be kept in memory, in the same process as the code that's using it.
I think something like Sandstorm's grains or Cloudflare's Durable Objects (used in conjunction with Cloudflare Workers) is a much better design. Of these two, Sandstorm grains were particularly interesting to me, because a grain could run arbitrary Linux programs. I hope that when Cloudflare finally reveals its edge containers product [1], it looks a lot like Sandstorm grains.
The strong guarantee of isolation for WebAssembly in particular (stronger than that of isolates for Node.js code) comes from the WASM runtime's use of bytecode with no "escape hatch" to native code (no loading of native modules); and the WASM abstract machine's isolated memory model.
Technically, though, I don't think this gets Cloudflare much in latency terms over doing efficient concurrent binary IPC over local Unix sockets, ala the Erlang "C node" model (https://www.erlang.org/doc/tutorial/overview.html#c-nodes). Due to the aforementioned isolated memory model, even a process-embedded WASM isolate will still require a memcpy(2) to exchange data into and out of the isolate. Unless Cloudflare have hacked up something custom, there's no way to do zero-copy SHM messaging with a WASM program.
This approach is interesting, and it a natural extension of any language. You do have to careful of side effects (and cost). I had a lot of trouble trying to make this approach work, and invented a language to satisfy my particular requirements ( https://www.adama-platform.com/ ).
I'm having tons of fun, but im enjoying reading the history of eigr as I feel a kinship in this space.
Ok, I'm not one of those who consider the naming of the "master" branch in git offensive, but naming your service proxy "massa" (https://www.urbandictionary.com/define.php?term=massa) sounds a bit... unfortunate, even to my ears.
Believe you me, I even visited that region once, so I am familiar with the Eiger (as well as the Mönch and Jungfrau) peaks, as well as the Aletsch glacier, but I had never heard of the Massa river before (probably because it only has that name for 7 km before it flows into the Rhône). So I still think the naming is unfortunate...
There are cities, rivers, companies, people named Massa in Europe. A people and it’s language in Africa. A unit in India… even in medicine: Massa lateralis.
Using a TikTok trend in the US for taking offense is… petty?
I wasn't taking offense, I only wrote that the naming is unfortunate - and I wasn't referring to the TikTok trend, I was referring to the widely-known fact that African American slaves called their masters "massa" (the first part of the definition). And that name, used for a service proxy, may have people jumping to the wrong conclusion...
Seems rather quiet.
from https://eigr.io/docs/history/
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.
It seems the author gave a talk about it in August 2021. It looks alive :)
The project is alive :) Last week at CodeBEAM Europe 2022 in Stockholm, we gave an update in our talk there about it and its context in todays journeys (enterprise) companies aim to move to the cloud. http://codesync.global/conferences/code-beam-sto-2022
IIUC, this is using Elixir for the orchestration layer, but that layer is spawning processes in other programming languages, communicating with those processes over gRPC, passing state into short-lived requests in those processes, and then getting new state back in the responses. Please correct me if I'm wrong.
IMO, that approach is irreparably inefficient, because state has to be passed back and forth, rather than being stored locally over the length of a longer operation. Yes, one has to checkpoint state to be able to recover from various events, but on the happy path, it should be kept in memory, in the same process as the code that's using it.
I think something like Sandstorm's grains or Cloudflare's Durable Objects (used in conjunction with Cloudflare Workers) is a much better design. Of these two, Sandstorm grains were particularly interesting to me, because a grain could run arbitrary Linux programs. I hope that when Cloudflare finally reveals its edge containers product [1], it looks a lot like Sandstorm grains.
[1]: https://blog.cloudflare.com/containers-on-the-edge/
> it should be kept in memory, in the same process as the code that's using it
how do you do that in a polyglot Environment?
Also note, that Erlang processes are not the same as OS processes and are much lighter.
> how do you do that in a polyglot Environment?
Cloudflare Workers does it by using a WebAssembly runtime (https://developers.cloudflare.com/workers/platform/languages...). You compile your C/Go/Rust/whatever code to WASM, and the embedded WASM runtime executes them at "almost native" speed.
Whichever runtime they use (probably WAVM?), it has support for "isolates" in the V8 sense (https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_is...), which work effectively as sandboxes without requiring host:guest process isolation.
The strong guarantee of isolation for WebAssembly in particular (stronger than that of isolates for Node.js code) comes from the WASM runtime's use of bytecode with no "escape hatch" to native code (no loading of native modules); and the WASM abstract machine's isolated memory model.
Technically, though, I don't think this gets Cloudflare much in latency terms over doing efficient concurrent binary IPC over local Unix sockets, ala the Erlang "C node" model (https://www.erlang.org/doc/tutorial/overview.html#c-nodes). Due to the aforementioned isolated memory model, even a process-embedded WASM isolate will still require a memcpy(2) to exchange data into and out of the isolate. Unless Cloudflare have hacked up something custom, there's no way to do zero-copy SHM messaging with a WASM program.
This approach is interesting, and it a natural extension of any language. You do have to careful of side effects (and cost). I had a lot of trouble trying to make this approach work, and invented a language to satisfy my particular requirements ( https://www.adama-platform.com/ ).
I'm having tons of fun, but im enjoying reading the history of eigr as I feel a kinship in this space.
it's not in the box, it's in the beam
Ok, I'm not one of those who consider the naming of the "master" branch in git offensive, but naming your service proxy "massa" (https://www.urbandictionary.com/define.php?term=massa) sounds a bit... unfortunate, even to my ears.
From readme in tehir github repo:
> The name Massa is due to a river near the Eiger mountain in Switzerland
Even though HN crowd is US centric, there are people, cultures, languages and places outside of US too.
Believe you me, I even visited that region once, so I am familiar with the Eiger (as well as the Mönch and Jungfrau) peaks, as well as the Aletsch glacier, but I had never heard of the Massa river before (probably because it only has that name for 7 km before it flows into the Rhône). So I still think the naming is unfortunate...
There are cities, rivers, companies, people named Massa in Europe. A people and it’s language in Africa. A unit in India… even in medicine: Massa lateralis.
Using a TikTok trend in the US for taking offense is… petty?
I wasn't taking offense, I only wrote that the naming is unfortunate - and I wasn't referring to the TikTok trend, I was referring to the widely-known fact that African American slaves called their masters "massa" (the first part of the definition). And that name, used for a service proxy, may have people jumping to the wrong conclusion...