Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proto Actor – Fast distributed actors for Golang and C#

proto.actor

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Proto Actor – Fast distributed actors for Golang and C#

#31

Post by mamcx »

di4na wrote: post #26
mamcx wrote: post #18

Earlier quoted context omitted.

Channels will be a better fit inside .NET? >powerful and often simpler than equivalent channel based systems, conceptually Without true experience with any of agents/channels, what make it simpler? I read the GO and compare with Actors in F# or Erlang and for me it easier to understand channels. Mainly because are typed on the data.

The thing is, Types are really hard to make work in a distributed unbounded non deterministic system like... well any system that is multi threaded. You can try to hide stuff with channels, but most of the time, you will feel the abstraction leaking.

I maybe can see if we are talking about distributed across machines, runtimes with different versions or languages, but not with multi threaded. Any example?

Re: Proto Actor – Fast distributed actors for Golang and C#

#32

Post by KirinDave »

macintux wrote: post #12
KirinDave wrote: post #8

We should be really skeptical of (or perhaps we could charitably say, "We should contextualize these,") speed claims. Akka does well in benchmarks too, until you put significant memory pressure on the VM and find it handles less gracefully under load than a more JVM-natural approach using approaches in java.util.concurrent. Actor-based approaches with hundreds of thousands of actors are really amazing, powerful and o…

My favorite conference talk is about the multiple facets of Erlang that combine to make it such a great language. Take an opinionated language, an opinionated VM, and a focus on a specific problem space, and magic happens. Take one or two features from Erlang into another language, and you have meh.

Welllllllll...

Can I be honest? As a language, Erlang kinda is a cube of frozen barf. It's not messy, but it's certainly not delicious. I do not "love it." I think most people sort of work around this; OTP is so good you put up with a kinda ugly syntactic substrate. Ideas good, array syntax bad, etc.

Re: Proto Actor – Fast distributed actors for Golang and C#

#33

Post by KirinDave »

mamcx wrote: post #18
KirinDave wrote: post #8

We should be really skeptical of (or perhaps we could charitably say, "We should contextualize these,") speed claims. Akka does well in benchmarks too, until you put significant memory pressure on the VM and find it handles less gracefully under load than a more JVM-natural approach using approaches in java.util.concurrent. Actor-based approaches with hundreds of thousands of actors are really amazing, powerful and o…

Channels will be a better fit inside .NET? >powerful and often simpler than equivalent channel based systems, conceptually Without true experience with any of agents/channels, what make it simpler? I read the GO and compare with Actors in F# or Erlang and for me it easier to understand channels. Mainly because are typed on the data.

> Channels will be a better fit inside .NET?

I suppose?

> Without true experience with any of agents/channels, what make it simpler?

If you are very clear about not retaining references to things you ship to another actor, Erlang is marvelously concurrent without any of the usual considerations for shared memory or functional programming we have to make. You can confidently manipulate and mutate variables in your actor scope because your actor is single threaded and OTP makes async-with-response calls trivial to mix in with this when you want function semantics.

Actor based systems give you a place to put sequential mutation code and a clear, clean, scalable way to define parallel operations. Channels really... well they give you this blunt force instrument to export data but you end up implementing actor-like management every time they're invoked if you're doing any sort of fan-out anyways.

Re: Proto Actor – Fast distributed actors for Golang and C#

#34

Post by megakid »

RogerAlsing wrote: post #28
ex3ndr wrote: post #3

Not sure why it should be trusted more than Akka or Akka.Net. Akka is much much more than just "actors".

Founder of both Akka.NET and Proto.Actor here. Right now, Proto.Actor-dotnet should not be trusted more than Akka.NET. Akka.NET is production ready and has a huge community. has commercial support etc. There are however a fair number of design issues that I dislike personally which led me to start Proto.Actor The .NET implementation of proto.actor is in alpha version right now. We are building and stabilizing the Go…

Roger, lurker on Akka.NET and about to start an Akka.NET PoC at work - proto.actor looks interesting - Can you elaborate on the design issues you have with Akka.NET?

Re: Proto Actor – Fast distributed actors for Golang and C#

#35

Post by saturn_vk »

mi100hael wrote: post #5

.NET and Go are a weird pairing, especially since the library isn't actually "cross-platform." It's two separate implementations. I wonder what the impetus was to develop this library on those two particular platforms, especially since there's already Akka.NET and most people can't shut up about how much they love Goroutines as a concurrency primitive.

The author of this wrote Akka.net first, then wrote GAM (the original name of this project, supporting only go), then implemented the net counterpart

Re: Proto Actor – Fast distributed actors for Golang and C#

#36

Post by RogerAlsing »

megakid wrote: post #34
RogerAlsing wrote: post #28

Earlier quoted context omitted.

Founder of both Akka.NET and Proto.Actor here. Right now, Proto.Actor-dotnet should not be trusted more than Akka.NET. Akka.NET is production ready and has a huge community. has commercial support etc. There are however a fair number of design issues that I dislike personally which led me to start Proto.Actor The .NET implementation of proto.actor is in alpha version right now. We are building and stabilizing the Go…

Roger, lurker on Akka.NET and about to start an Akka.NET PoC at work - proto.actor looks interesting - Can you elaborate on the design issues you have with Akka.NET?

Sure.

Serialization and the concept of the ActorRef. They both go hand in hand.

in Akka/NET, ActorRefs are contextual, they belong to a given ActorSystem.

This means that when they are serialized, the serializer needs to be able to know how to transfer and rebind this context on serialization and deserialization. To make it more complex, ActorRefs can be embedded in other messages. There are a few other primitives also that are contextual and serialized. This limits the options you have in terms of serializers. It also puts a massive tax on the framework in terms of maintenance.

ActorRefs are also "resolved" when deserialized, so the deserializing system has to figure out which actor is targeted. This lookup is slow due to parsing and scanning of actors and their children.

This makes network communication speed suffer _a lot_.

The configuration DSL HOCON is also tightly integrated with the entire infrastructure, making it hard to reason about what is going on and what parts of the config the current piece of code actually sees. Akka/NET also lacks good interception points, its hard to hook into actors and monitor them.

There are just too many moving parts for my own liking. I did blog about some of the problem areas in my POV about a year ago: https://rogerjohansson.blog/2016/03/13/random-things-learned...

So the issues are really both on a performance level and at a maintenance level.

The mindset in Akka.NET have been more "lets build everything ourselves from scratch to match the JVM" and in proto.actor "lets re-use proven tech and glue them together, with minimal code"

Re: Proto Actor – Fast distributed actors for Golang and C#

#37

Post by di4na »

mamcx wrote: post #31
di4na wrote: post #26

Earlier quoted context omitted.

The thing is, Types are really hard to make work in a distributed unbounded non deterministic system like... well any system that is multi threaded. You can try to hide stuff with channels, but most of the time, you will feel the abstraction leaking.

I maybe can see if we are talking about distributed across machines, runtimes with different versions or languages, but not with multi threaded. Any example?

What is the difference between multithread and different machines? Time to get a synchronous response ? At best. But errors happens to and error situations are the same.

Re: Proto Actor – Fast distributed actors for Golang and C#

#38

Post by alexeiz »

mavam wrote: post #30
KirinDave wrote: post #8

We should be really skeptical of (or perhaps we could charitably say, "We should contextualize these,") speed claims. Akka does well in benchmarks too, until you put significant memory pressure on the VM and find it handles less gracefully under load than a more JVM-natural approach using approaches in java.util.concurrent. Actor-based approaches with hundreds of thousands of actors are really amazing, powerful and o…

(Disclaimer: CAF co-maintainer here.) It's great to see more actor runtimes on the rise. Also interesting to see the actor model implemented in Go, which follows more of a pi calculus design with its channels. With an actor design, the software architecture shifts towards the endpoints of the communication. CAF targets the performance-sensitive C++ community, so sending a message in the same process only costs a sing…

I've been using the CAF library for a while, and the experience so far has been very positive. It's surprisingly capable and flexible at the same time. The use of modern C++ in CAF makes your code very clean and idiomatic. Other C++ libraries of this kind are usually quite painful to use (because you know, most people think if it's C++ it has to be hard). CAF is a pleasant exception to this rule.

Re: Proto Actor – Fast distributed actors for Golang and C#

#39

Post by mamcx »

KirinDave wrote: post #33
mamcx wrote: post #18

Earlier quoted context omitted.

Channels will be a better fit inside .NET? >powerful and often simpler than equivalent channel based systems, conceptually Without true experience with any of agents/channels, what make it simpler? I read the GO and compare with Actors in F# or Erlang and for me it easier to understand channels. Mainly because are typed on the data.

> Channels will be a better fit inside .NET? I suppose? > Without true experience with any of agents/channels, what make it simpler? If you are very clear about not retaining references to things you ship to another actor, Erlang is marvelously concurrent without any of the usual considerations for shared memory or functional programming we have to make. You can confidently manipulate and mutate variables in your act…

Ok, this make it clear a true advantage, having the mutations (and I assume, stack and related) isolated is compelling.

I imagine this is the reason for build a custom-made VM, and not be a good fit inside Java/.NET?

Re: Proto Actor – Fast distributed actors for Golang and C#

#40

Post by mamcx »

di4na wrote: post #37
mamcx wrote: post #31

Earlier quoted context omitted.

I maybe can see if we are talking about distributed across machines, runtimes with different versions or languages, but not with multi threaded. Any example?

What is the difference between multithread and different machines? Time to get a synchronous response ? At best. But errors happens to and error situations are the same.

But why are types a problem?
Post reply on HN