I'm getting a "Page not Found" from this link.
Proto Actor – Fast distributed actors for Golang and C#
21–30 of 47 posts
Re: Proto Actor – Fast distributed actors for Golang and C#
#22I've captured a few other open source actor implementations: https://gist.github.com/macintux/6349828#other-actor-impleme...
Re: Proto Actor – Fast distributed actors for Golang and C#
#23Earlier quoted context omitted.
Considering the production system that the Erlang VM has been deployed to(and the length of time it's existed and thrived) it's hard to make an argument to re-invent it in another language. If that's what your domain space needs, use the BEAM and find a way to talk to it for the parts that you can't move to Erlang.
It's not hard to justify; that's laughable. It's simple redundancy!
Sometimes the concurrency benefits just don't add up when compared to other business/project concerns.
I say this as an big fan of Erlang, truth is, sometimes you just have to accept that your job is to write a python/Django backend without a line of JavaScript in order to serve as a line of business app, and if the load gets bigger, you just throw another server at it.
That said, erlang is great, elixir is awesome, and both are 100% worth every developers time to learn.
Re: Proto Actor – Fast distributed actors for Golang and C#
#24Most of my non trivial goroutines are organized like this: func actor_foo(things) error { set_up_stuff() defer clean_up_stuff() for { select { case msg := I recognize there is more to the actor model than just message loops, but I found that an explicit for-select-switch results in better overall readability.
Is signals your "done" channel?
I was just trying to convey an example. I usually "signal" that the parent wants to stop this "actor" for some reason (e.g graceful shutdown).
If parent need a "done" channel, it passes it in and "actor" closes it on its way out.
Cleanup usually "signals" children and waits for them to be "done".
Sometimes "done" is just signalled by the goroutine returning and it is wrapped in parent somehow.
But every time I try to formalize it into some "framework" my abstraction fails.
Re: Proto Actor – Fast distributed actors for Golang and C#
#25Earlier quoted context omitted.
It's not hard to justify; that's laughable. It's simple redundancy!
Sometimes the concurrency benefits just don't add up when compared to other business/project concerns. I say this as an big fan of Erlang, truth is, sometimes you just have to accept that your job is to write a python/Django backend without a line of JavaScript in order to serve as a line of business app, and if the load gets bigger, you just throw another server at it. That said, erlang is great, elixir is awesome,…
I'm not sure where concurrency plays into this at all.
Re: Proto Actor – Fast distributed actors for Golang and C#
#26We 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.
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.
Re: Proto Actor – Fast distributed actors for Golang and C#
#27Most of my non trivial goroutines are organized like this: func actor_foo(things) error { set_up_stuff() defer clean_up_stuff() for { select { case msg := I recognize there is more to the actor model than just message loops, but I found that an explicit for-select-switch results in better overall readability.
the only challenge here is that upstream senders will block when your channel(s) are full. This is not inherently bad, but if you have a circular dependency, you can deadlock because queues (channels) are bounded and may fill up. There are solutions to that too, but you have to build that in
Re: Proto Actor – Fast distributed actors for Golang and C#
#28Not 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 version first, which already is used in major production systems.
Re: Proto Actor – Fast distributed actors for Golang and C#
#29One of the major things will be the tooling around it.
As we work with a well defined schema. we can create tools that work for all implementations.
e.g. see this CLI tool for managing proto.actor systems live: https://asciinema.org/a/a1b18jiv703e6eog1o2b7domi
You will be able to send messages to actors, connect to remote nodes etc.
There are also very fine-grained interception points allowing us to plug in things like zipkin.io w/o altering how the user writes their code.
Re: Proto Actor – Fast distributed actors for Golang and C#
#30We 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 single hardware-support CAS operation. We found this scales very well. No GC other than reference counting.
For those interested in learning more about actors in the C++ ecosystem, I recently gave a talk about CAF and some performance comparisons to other frameworks in various scenarios: http://matthias.vallentin.net/slides/caf-rise.pdf