Going cross platform

[rogeralsing]

Languages and frameworks like Erlang/Elixir, Akka, Akka.NET, ServiceFabric and Microsoft Orleans, are all incompatible. there is no actor native way of communicating between the different stacks.
(You can ofcourse integrate using HTTP or via message queues, but this is not the question asked here)

GAM is built from day one to support cross platform actors.
We use gRPC Streams for remote communication, Protobuf for serialization.
There is no fancy API tricks or strange local thread state required.
It is all standard technologies composed together.
The TLDR; description is that it is gRPC services with actor infrastucture behind the endpoints.

Is there any serious interest in having fully cross platform actors, both Akka and MS Orleans style virtual actors for other platforms?
If so, what platforms should we focus on?

e.g. Is there an interest of having distributed and virtual actors for Rust?
Is there an interest to be able to integrate clustered .NET software with Go?

For those new to GAM, here is a quick recap of features offered.

See: https://github.com/AsynkronIT/gam#go-actor-model

• In process actors, similar to Akka
• Statemachine support through Become semantics
• Supervision trees
• Message routing
• Pluggable message pipeline
• Location transparency, extremely fast networking support
• Persistence, Event/Command sourcing
• Cluster support
• Virtual Actors, similar to Microsoft Orleans, Service Fabric, Orbit

What I am trying to get at here is that:

• There are other ongoing efforts on other platforms, should we try to unite them?
• There is an actual business need to have an exit strategy from one platform to another

[rogeralsing]

[nsomaru]

Perhaps ASGI (Asynchronous Server Gateway Interface) Draft Spec from django-channels (http://channels.readthedocs.io/en/stable/asgi.html)?

[MedAnd]

I would be very interested in a Service Fabric implementation using gRPC as the transport. I suspect there could be some perf gains... What do you think about hosting GAM within Service Fabric, integrating with the Service Discovery and communicating with other services implemented in .Net via gRPC?

[rogeralsing]

@MedAnd it should be doable

[MedAnd]

One other thought if possible, have GAM import/call into the Service Fabric reliable collections via native code, thus implement servicefabric_persistence for actors.

[ReubenBond]

@MedAnd, the SF reliable collections were written in C# and use higher level .NET APIs which native code does not provide.

[MedAnd]

@ReubenBond Thought this was the case, assume the SF reliable collections are being actively ported to C++ as part of the Service Fabric on Linux initiative... maybe stage one just GAM and SF integrated and talking via gRPC...

[rogeralsing]

This is in progress, C# implementation exists.

[rogeralsing]

@tomaszchacuk you might be interested in this.
Saw your post on cross platform Akka.

[ethanfrey]

I am looking for cross-language actor model implementations and came across your project, which seems the most developed example of such. After experimenting with various concurrency mechanisms and dealing with synchronization, the actor model has shown to make it much simpler to prove correctness.

I mainly write golang, and would like to start writing components in go, but similar to microservice architectures, I figured that remote actors could be implemented in different languages. We discuss migrating to rust in the mid-term, and would be interested in investigating porting to Rust as well.

My main question is where is the specification that all implementations adhere to? So far I could only find https://github.com/AsynkronIT/protoactor-contracts as truly language-independent. Also, https://github.com/actix/actix seems quite well maintained in Rust, and I wonder if it would make sense just to wrap this library with a common gRPC/protobuf API to make it interoperable with the golang and C# versions.

[rogeralsing]

I would love to see a Rust port of ProtoActor. but personally I have no experience with Rust. nor do I have the time to invest right now.

I can however help answer all details around implementation.

[ethanfrey]

Thank you for the response and offer of information. I am currently doing research on libraries and would need to implement a bit in golang before even considering a port.

My question is what is the shared API that the various implementations must all implement?
The internal API may be different, but the communication protocol between nodes in different languages must be standardized.

I am a big fan of protobuf, not because it is beautiful, but because it has solid tooling in many languages and platforms and just works. And completely agree with the decision to leverage existing tools rather than reinvent the wheel.

If there is an API spec to share, that would be great. If not, I will come back with some more detailed questions after getting a prototype system working in golang. (Give me a few weeks)