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

41–50 of 95 posts

Re: Actor system for the JVM developed by Electronic Arts

#41

Post by solaxun »

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…

Out of curiosity (not much experience with Actor systems), do these systems solve a different problem than having disparate processes communicate by sticking a distributed message queue between them? From my naive point of view it seems like alot of the scaling and fault tolerance concerns nowadays can be solved in any language, by having a queue be the interface between two services.

Same question applies to Erlang, which I realize is not exactly an actor system as per the below comment, and has a much more sophisticated error recovery story with supervisors, but the general question holds.

Re: Actor system for the JVM developed by Electronic Arts

#42

Post by lostcolony »

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…

>> With that being said, the actor model has a lot of inherent complexity. If you don’t need it, don’t use it. But if you really do need lots of concurrency and lots of mutable state, it’s often a great choice.

I kind of disagree with this. I mean, it's kind of correct, if you literally have a sequential problem with immutable state you're gaining nothing from it, but you're also losing nothing (you...will have one actor, no messages being passed, so the only cost is the syntax of the language; the actor model isn't adding any complexity because you aren't using it).

But, a lot of problems we've historically learned to view as sequential are in fact concurrent. Deeply concurrent. We've created entire concepts specifically to impose sequential processing upon innately concurrent activities.

As an example, almost everywhere we use queues we could instead model as unrelated processes able to be run concurrently. You still may have a bit of queueing/scheduling for unbounded processes, but I know from production experience that that is far, far simpler to do and get right using actors than a traditional queue/priority queue and worker(s).

And that's where it shines. It encourages you to start thinking about what in fact -should- be done concurrently, by making that easy rather than a chore as it is in most other languages, and that leads to -less- complexity.

Re: Actor system for the JVM developed by Electronic Arts

#43

Post by sandGorgon »

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.

Re: Actor system for the JVM developed by Electronic Arts

#44

Post by bcrosby95 »

lostcolony wrote: post #42
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…

>> With that being said, the actor model has a lot of inherent complexity. If you don’t need it, don’t use it. But if you really do need lots of concurrency and lots of mutable state, it’s often a great choice. I kind of disagree with this. I mean, it's kind of correct, if you literally have a sequential problem with immutable state you're gaining nothing from it, but you're also losing nothing (you...will have one a…

I'm curious what you see as so different in an actor vs a queue with workers. An actor's mailbox effectively acts as a queue.

Is it the supporting structure surrounding an actor focused library/language? Lots of person-hours have gone into making them to work well. Some home grown queue + pool of threads working off that queue... not so much.

Re: Actor system for the JVM developed by Electronic Arts

#47

Post by ctvo »

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?

This is a very broad question. I would start with understanding the concept of actors. You'll end up reading about Erlang, Akka, etc.

Then what's a virtual actor and how does it differ? You'll eventually end up at the Orleans paper from MSFT research:

https://www.microsoft.com/en-us/research/publication/orleans...

It really has nothing to do with promises (as used colloquially) and is a way to design large distributed systems using message passing and localized state that's persisted.

Re: Actor system for the JVM developed by Electronic Arts

#48

Post by guipsp »

qlm wrote: post #18
g051051 wrote: post #17

It'd be a lot more interesting if it wasn't in Kotlin.

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.

Re: Actor system for the JVM developed by Electronic Arts

#49

Post by ackfoobar »

bcrosby95 wrote: post #44
lostcolony wrote: post #42

Earlier quoted context omitted.

>> With that being said, the actor model has a lot of inherent complexity. If you don’t need it, don’t use it. But if you really do need lots of concurrency and lots of mutable state, it’s often a great choice. I kind of disagree with this. I mean, it's kind of correct, if you literally have a sequential problem with immutable state you're gaining nothing from it, but you're also losing nothing (you...will have one a…

I'm curious what you see as so different in an actor vs a queue with workers. An actor's mailbox effectively acts as a queue. Is it the supporting structure surrounding an actor focused library/language? Lots of person-hours have gone into making them to work well. Some home grown queue + pool of threads working off that queue... not so much.

You're exactly right.

Some examples:

- Some common patterns. E.g. actor hierachy and supervision, circuit breaker.

- Persistence. The actor persists its state (changes) and can wake up from a sleep.

- Clustering. The actor can live in another node, and you interact with it using the same API.

Re: Actor system for the JVM developed by Electronic Arts

#50

Post by [deleted] »

dijit wrote: post #24

Orbit is also the name of the always online DRM system that Ubisoft made many years ago. Fun fact, the tech that was developed to power Orbit forked and evolved along largely divergent paths to be Uplay and the framework on which the Division and Division 2 online backends were made. You can still see paths referencing Orbit in uplay, especially on the downloads: http://static3.cdn.ubi.com/orbit/launcher_installer/Ub…

[deleted]
Post reply on HN