Protoactor Go project positioning and future plans?

I recently bumped into proto.actor and very interested in the Go parts of the project. But I have some questions…

Recently the DotNet project seems more active. They are independent codebases. How are they related, i.e. kept in sync functionality / compatibility wise? Is Golang part of the long-term roadmap of proto.actor as something with prolonged commitment / support?

Related: The documentation is mostly focused on C# … is Golang the 2nd-class citizen?

How does Asynkron fit into the picture? What is your revenue model and relationship to proto.actor as an open-source project?

(Note: I first filed a Github issue for this, which I’ll close in favor of this topic)

@rogeralsing just answered on Github, while I posted the above. Continuing here…

Hello @aschrijver

Absolutely, Inlining per question here:

Starting in reverse order:

How does Asynkron fit into the picture? What is your revenue model and relationship to proto.actor as an open-source project?

I’m the founder of Asynkron and the Proto.Actor project.
Asynkron as a company is the owner of the Proto.Actor trademark.
The opensource projects are also under a Contributors License Agreement, which grants Asynkron the signed license to use the contributed code.

Under Asynkron, we offer consulting services around scalability, distributed systems, workshops, training sessions around the actor model in general, and Proto.Actor as a framework, e.g. helping clients architect and implement Proto.Actor systems.

We are currently in negotiations with a potential partner company for setting up a full set of support plans for Proto.Actor.
Offering developer support and full-fledged 24/7 SLA production support.

How are they related, i.e. kept in sync functionality / compatibility wise? Is Golang part of the long-term roadmap of proto.actor as something with prolonged commitment / support?

The plan is to keep the two fully in sync. currently working on porting over all the new cluster features from .NET to Go.
Which project gets the most attention depends very much on where there currently are the most contributors, and what clients we are working with. e.g. I am working full time with a .NET customer right now, which leads to more progress on the .NET version.

Personally, I do believe Proto.Actor Go has a brighter future as Go generally is more used in the high-scalability world.

Hope this sheds some light on your questions?

Let me know if there is anything that I can elaborate on

Hello @aschrijver

Absolutely, Inlining per question here:

Starting in reverse order:

How does Asynkron fit into the picture? What is your revenue model and relationship to proto.actor as an open-source project?

I’m the founder of Asynkron and the Proto.Actor project.
Asynkron as a company is the owner of the Proto.Actor trademark.
The opensource projects are also under a Contributors License Agreement, which grants Asynkron the signed license to use the contributed code.

Under Asynkron, we offer consulting services around scalability, distributed systems, workshops, training sessions around the actor model in general, and Proto.Actor as a framework, e.g. helping clients architect and implement Proto.Actor systems.

We are currently in negotiations with a potential partner company for setting up a full set of support plans for Proto.Actor.
Offering developer support and full-fledged 24/7 SLA production support.

How are they related, i.e. kept in sync functionality / compatibility wise? Is Golang part of the long-term roadmap of proto.actor as something with prolonged commitment / support?

The plan is to keep the two fully in sync. currently working on porting over all the new cluster features from .NET to Go.
Which project gets the most attention depends very much on where there currently are the most contributors, and what clients we are working with. e.g. I am working full time with a .NET customer right now, which leads to more progress on the .NET version.

Personally, I do believe Proto.Actor Go has a brighter future as Go generally is more used in the high-scalability world.

Hope this sheds some light on your questions?

Let me know if there is anything that I can elaborate on

1 Like

I won’t be using gRPC over the network (where I use AP), but was intending to use Hashicorp’s go-plugin (which uses gRPC) to have a dynamic plugin system and ability to add/remove module extensions dynamically at runtime. I still need to check if/how this can be combined with proto.actor (Proto.Remote?).

This is an interesting topic, we are sketching on how to offer this out of the box.
We have two similar but different in scope size approaches for this.
The first is to allow for actor plugins, e.g. making it possible to hook the actor receive pipeline to a chain of external services.
@alexeyzimarev is involved in this also. as the primary use-case is for our shared client project.

The other approach we have is to offer a Proto.Serverless module, which would build on a form of shapeless actors which only hold raw state in binary form, which then push this state and incoming messages to external services over gRPC.
allowing actor logic to be written in any language.

1 Like

Thank you for all the information. It answers my question.

On the Go side there may be more cultural barriers to overcome, with a build-your-own attitude, avoiding dependencies / frameworks. Don’t know about actor model, but DDD/CQRS is much more familiar concept in the MS .NET world for a long time. Building high-perf business applications in Go is an upcoming trend. I’d say on the whole this means opportunities…

Curious how the project will unfold on these aspects in the coming time. The ability for plugins to be polyglot is a super attractive feature.

On the whole I feel the project will benefit a lot in terms of early uptake with lotsa documentation, examples and example code that goes beyond Hello World. I see you are making strides there. All looks really promising.