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

Actor system for the JVM developed by Electronic Arts

orbit.cloud

Post reply on HN
Print view View original

31–40 of 95 posts

Re: Actor system for the JVM developed by Electronic Arts

#31

Post by dragonwriter »

yashap wrote: post #29
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…

Agreed, although it’s not always fire-and-forget (i.e. send a message and don’t wait for a response). Actors generally do support request/response style messaging, but it’s always async - it’s really only synchronous request/response communication that’s not allowed.

> Agreed, although it’s not always fire-and-forget (i.e. send a message and don’t wait for a response).

Sure, you can do async request/response in the actor model, but the low-level basic mechanism all communication is built on is send a message to an actor mailbox and keep going. Everything else is built in top of that.

Re: Actor system for the JVM developed by Electronic Arts

#32

Post by spinningslate »

yashap wrote: post #22
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?

Actors are useful for keeping code clean/understandable/correct when dealing with heavy concurrency AND lots of mutable state. Actors are like objects, but the only way to interact with them is sending them a message - you can’t directly access their properties, call their methods, etc. Messages are bits of immutable data sent between actors asynchronously, but those messages go into the actor’s mailbox, and then the…

> 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, Pony) do not support that pipelining so are single threaded per actor as you state though. As an aside, the behaviour you describe is part of the CSP formalism [1] - a related but different approach to concurrent systems.

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

[1]: https://en.wikipedia.org/wiki/Communicating_sequential_proce...

Re: Actor system for the JVM developed by Electronic Arts

#33

Post by baud147258 »

Pxtl wrote: post #14

I assume EA didn't make this just for funsies. What do they use it for?

from the article on its release:

http://blog.bioware.com/2015/03/30/launching-into-orbit/

(HN thread: https://news.ycombinator.com/item?id=9300672)

> The last-generation of Orbit powered some of the key technology behind the Dragon Age Keep and Dragon Age: Inquisition. Our plans for the next-generation framework are even more ambitious.

So at least it was used for some of Bioware's games

Re: Actor system for the JVM developed by Electronic Arts

#38

Post by throwawaymaths »

spinningslate wrote: post #32
yashap wrote: post #22

Earlier quoted context omitted.

Actors are useful for keeping code clean/understandable/correct when dealing with heavy concurrency AND lots of mutable state. Actors are like objects, but the only way to interact with them is sending them a message - you can’t directly access their properties, call their methods, etc. Messages are bits of immutable data sent between actors asynchronously, but those messages go into the actor’s mailbox, and then the…

> 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 of jumping on the "actor" (and later, "OOP") bandwagons as marketing? to try to make Erlang less scary.

Post reply on HN