Actor system for the JVM developed by Electronic Arts • Hacker News Board

Re: Actor system for the JVM developed by Electronic Arts

#61

Post by spinningslate » Thu, Apr 28, 2022, 7:47 PM UTC

throwawaymaths wrote: post #38

spinningslate wrote: post #32

Earlier quoted context omitted.

> those messages go into the actor’s mailbox, and then the actor processes them synchronously Not trying to be pedantic, but that's technically not true of the Actor formalism [0]. Quoting wikipedia: > an actor can designate the behavior to be used to process the next message, and then in fact begin processing another message M2 before it has finished processing M1. Available implementations (such as Erlang, Akka, Po…

Just to be a bit pedantic (but important), Erlang is not an actor system. It's a system designed for fault tolerance and definable failure domains. Concurrency fell out of those requirements and it just happens to vaguely look like an actor system if you squint hard enough. I don't believe theories of actor systems played into the design of Erlang. Perhaps some of the blame belongs on the creators of Erlang for kind…

Fair point: Erlang wasn't designed as an Actor system. But you don't have to squint that hard to see the similarities. Again quoting wikipedia [0]:

> An actor is a computational entity that, in response to a message it receives, can concurrently:

    send a finite number of messages to other actors;
    create a finite number of new actors;
    designate the behavior to be used for the next message it receives.

> There is no assumed sequence to the above actions and they could be carried out in parallel.

All above are true of Erlang except intra-actor concurrency. Even the last bullet on designating behaviour: An Erlang process (actor equivalent) can decide to use a different function when receiving the next message. It just can't pipeline handling messages.

So Erlang isn't that far removed from the Actor model in its behaviour, even if it wasn't designed as an Actor system in the first place. One might say actors are an (approximate) emergent property of Erlang rather than an intentionally designed one.

Slightly off-topic but the only system I've used that was designed & built from the outset as an actor system is Rosette [1]. It was a really interesting project, and does support pipelining, but has been dormant for more than a decade.

[0]: https://en.wikipedia.org/wiki/Actor_model#Fundamental_concep...

[1]: https://github.com/leithaus/Rosette

--

EDIT: clarified that Rosette is the only system I've used that was explicitly based on the Actor model from the outset.

Re: Actor system for the JVM developed by Electronic Arts

#62

Post by bitwalker » Thu, Apr 28, 2022, 7:49 PM UTC

throwawaymaths wrote: post #38

spinningslate wrote: post #32

Earlier quoted context omitted.

> those messages go into the actor’s mailbox, and then the actor processes them synchronously Not trying to be pedantic, but that's technically not true of the Actor formalism [0]. Quoting wikipedia: > an actor can designate the behavior to be used to process the next message, and then in fact begin processing another message M2 before it has finished processing M1. Available implementations (such as Erlang, Akka, Po…

Just to be a bit pedantic (but important), Erlang is not an actor system. It's a system designed for fault tolerance and definable failure domains. Concurrency fell out of those requirements and it just happens to vaguely look like an actor system if you squint hard enough. I don't believe theories of actor systems played into the design of Erlang. Perhaps some of the blame belongs on the creators of Erlang for kind…

I mean, if it doesn't count as an implementation of an actor system, then I'm not sure what does, regardless of whether it was incidental to the design goals of Erlang as a language. It certainly walks and quacks like an actor system in my opinion, and I don't think you have to squint very hard at all to see it.

Perhaps we have different ideas of what an "actor system" is though.

Re: Actor system for the JVM developed by Electronic Arts

#63

Post by spacemanmatt » Thu, Apr 28, 2022, 8:23 PM UTC

sandGorgon wrote: post #43

a very interesting counterpoint is Vert.x - https://vertx.io/docs/vertx-core/java/ Vert.x uses a concept called Verticles - which are like actors..with an external message bus. Which ends up being more practical if you start leveraging kafka, etc in the architecture.

Vert.x has grown on me fast! Verticles are the right combination of actors and good-old pragma.

The community is healthy and helpful, too. I hope to stick with Vert.x for a long time even.

Re: Actor system for the JVM developed by Electronic Arts

#64

Post by spacemanmatt » Thu, Apr 28, 2022, 8:25 PM UTC

guipsp wrote: post #48

qlm wrote: post #18

Earlier quoted context omitted.

Why does that matter? Kotlin has interop with other JVM languages.

It does seem that some of the more interesting features require kotlin, which makes calling it an actor system for the jvm a bit meh, in my opinion.

You might be a candidate for Vert.x

Re: Actor system for the JVM developed by Electronic Arts

#65

Post by macintux » Thu, Apr 28, 2022, 8:37 PM UTC

bitwalker wrote: post #62

throwawaymaths wrote: post #38

Earlier quoted context omitted.

Just to be a bit pedantic (but important), Erlang is not an actor system. It's a system designed for fault tolerance and definable failure domains. Concurrency fell out of those requirements and it just happens to vaguely look like an actor system if you squint hard enough. I don't believe theories of actor systems played into the design of Erlang. Perhaps some of the blame belongs on the creators of Erlang for kind…

I mean, if it doesn't count as an implementation of an actor system, then I'm not sure what does, regardless of whether it was incidental to the design goals of Erlang as a language. It certainly walks and quacks like an actor system in my opinion, and I don't think you have to squint very hard at all to see it. Perhaps we have different ideas of what an "actor system" is though.

Dr. Hewitt typically chimes in on these threads to emphasize some of the differences between his model and Erlang. I don’t recall his username to locate some of those.

Re: Actor system for the JVM developed by Electronic Arts

#66

Post by macintux » Thu, Apr 28, 2022, 8:39 PM UTC

zo1 wrote: post #55

dragonwriter wrote: post #27

Earlier quoted context omitted.

> Actors are like objects, but the only way to interact with them is sending a message - you can’t access their properties, call their methods, etc. While the implementation in many popular, e.g. C++ and family descended from it, languages muddies the waters, basically methods in OO are a convenient way to define handlers for messages sent to objects, and in pure OO you also can't interact with objects except by send…

So much this. This "actor model" thing as described by GP sounds like plain old OO and RPC with extra steps and also distributed. This may be a low-effort post on my part, but I'm 100% not impressed because it sounds like marketing fluff and an opportunity to rewrite native/built-in things using frameworks. Also justifying Yet Another Framework or tool hosted on an .IO domain (snarky I know) for promotions and endles…

Erlang is decades old, a highly successful (for a relatively niche language, anyway) proof that the actor model (or something approximating it) can be a great tool.

Re: Actor system for the JVM developed by Electronic Arts

#67

Post by JoeHegarty » Thu, Apr 28, 2022, 8:59 PM UTC

giancarlostoro wrote: post #59

I found out about this one a few years back from a former (online) friend who worked on it (although I'm not entirely certain in his specific involvement, I want to say he was the lead developer initially though), his name is Joe Hegarty[0]. There was another implementation as well from him in TypeScript for Node.js called Ratatoskr[1]. As far as I've always known him, he always works on networking projects, I believ…

Thank you for your kind words. I do indeed still work on networking stuff.

Re: Actor system for the JVM developed by Electronic Arts

#68

Post by astrange » Thu, Apr 28, 2022, 9:03 PM UTC

zo1 wrote: post #55

dragonwriter wrote: post #27

Earlier quoted context omitted.

> Actors are like objects, but the only way to interact with them is sending a message - you can’t access their properties, call their methods, etc. While the implementation in many popular, e.g. C++ and family descended from it, languages muddies the waters, basically methods in OO are a convenient way to define handlers for messages sent to objects, and in pure OO you also can't interact with objects except by send…

So much this. This "actor model" thing as described by GP sounds like plain old OO and RPC with extra steps and also distributed. This may be a low-effort post on my part, but I'm 100% not impressed because it sounds like marketing fluff and an opportunity to rewrite native/built-in things using frameworks. Also justifying Yet Another Framework or tool hosted on an .IO domain (snarky I know) for promotions and endles…

CSP/actors is from the 70s, like most CS. It is sort of the original OO, but that's because OO is a newer version that's both less powerful and over-complicated.

It doesn't need to be distributed, and it's better not to include that because the approach to error handling gets a lot easier. If you're distributed every call can fail, be randomly slow, has marshaling costs, is untrusted, etc.

Re: Actor system for the JVM developed by Electronic Arts

#69

Post by usrusr » Thu, Apr 28, 2022, 9:20 PM UTC

pdpi wrote: post #6

gentleman11 wrote: post #3

> Orbit is a framework to write distributed systems using virtual actors on the JVM. A virtual actor is an object that interacts with the world using asynchronous messages. Could anybody elaborate on this? How does an actor differ from an object that uses promises to talk to a server?

Objects, actors, and (micro-)services are basically the exact same concept at different scales.

Thanks for making me feel old by not including agents in the list. Those seem even more similar to actors. At least until someone mentions BDI, then it's suddenly an entirely different universe.

Re: Actor system for the JVM developed by Electronic Arts

#70

Post by JoeHegarty » Thu, Apr 28, 2022, 9:31 PM UTC

So, I'm the original lead developer of this project.

This was meant to be a followup to the original version of Orbit which now lives on as orbit-legacy on GitHub.

Unfortunately other priorities have meant this project hasn't proceeded in the past couple of years. I wouldn't really recommend anyone use either of them.

However, the ideas and implementation both for Orbit Legacy and the early version of Orbit 2 contain some ideas and concepts that may be useful to folks.

I still think there is immense value in virtual actors (Orleans from Microsoft is one great alternative for .NET, and Dapr also looks interesting) but I can't say if we'll ever get back to it.