So, I'm the original lead developer of this project.<p>This was meant to be a followup to the original version of Orbit which now lives on as orbit-legacy on GitHub.<p>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.<p>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.<p>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.
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].<p>As far as I've always known him, he always works on networking projects, I believe he worked on the Fable 3 networking for coop and several other games. I can't even imagine what he works on at EA now honestly.<p>JoeH if you're reading this by chance: Just remember you were an inspiration back in the day (mid to late 2000s) to a lot of people who became developers and learned a ton from your work back then, myself included. To this day I remember asking you questions almost every day. Thank you for your efforts and your patience.<p>[0] <a href="https://www.joeh.ca/" rel="nofollow">https://www.joeh.ca/</a><p>[1] <a href="https://github.com/ratatoskr/ratatoskr" rel="nofollow">https://github.com/ratatoskr/ratatoskr</a>
The OSS project I work on, Dapr (Distributed Application Runtime - an incubated CNCF project) implements the virtual actor pattern if anyone is interested.<p><a href="https://docs.dapr.io/developing-applications/building-blocks/actors/actors-overview/" rel="nofollow">https://docs.dapr.io/developing-applications/building-blocks...</a><p><a href="https://github.com/dapr/dapr" rel="nofollow">https://github.com/dapr/dapr</a>
> 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.<p>Could anybody elaborate on this? How does an actor differ from an object that uses promises to talk to a server?
a very interesting counterpoint is Vert.x - <a href="https://vertx.io/docs/vertx-core/java/" rel="nofollow">https://vertx.io/docs/vertx-core/java/</a><p>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.
“Exactly one” is a hard concept to get right. How do they ensure that exactly one instance of an actor is alive at once, without sacrificing latency of actor start and/or while tolerating network partitions?
I'd like to mention the native actor model implementation CAF, the C++ Actor Framework, and share some experiences. (Disclaimer: I've been developing on CAF in the past and have a good relationship with the creator.) CAF (1) provides native actors without an VM layer, (2) type-safe interfaces so that the compiler yells at you when a receiver cannot handle a message, and (3) transparent copy-on-write messaging so that you can still push stuff through pipelines and induce only copies only when a ref count is greater than one.<p>In our telemetry engine VAST, we've been using CAF successfully for several years for building a distributed system that always has a saturated write path. CAF provides a credit-based streaming abstraction as well, so that you can have backpressure across a chain of actors, making burst-induced OOM issues a blast from the past. You also get all the other benefits of actors, like linking and monitoring, to achieve well-defined failure semantics: either be up and running or collectively fail, but still allowing for local recovery—except for segfaults, this is where "native" has a disadvantage over VM-based actor models.<p>With CAF's network transparent runtime, a message ender doesn't need to know where receiver lives; the runtime either passes the message as COW pointer to the receiver or serializes it transparently. Other actor model runtimes support that as well, but I'm mentioning it because our experience showed that this is great value: we can can slice and dice our actors based on the deployment target, e.g., execute the application in one single process (e.g., for a beefy box) or wrap actors into single OS processes (e.g., when deploying on container auto-scalers).<p>The deep integration with the C++ type system allowed us to define very stable RPC-like interfaces. We're currently designing a pub/sub layer as alternate access path, because users are interested in tapping into streaming feeds selectively. This is not easy, because request-response and pub/sub are two ends of a spectrum, but it turns out we can support nicely with CAF.<p>Resources:<p>- CAF: <a href="https://github.com/actor-framework/actor-framework" rel="nofollow">https://github.com/actor-framework/actor-framework</a><p>- VAST: <a href="https://tenzir.github.io/vast/docs/understand-vast/actor-model" rel="nofollow">https://tenzir.github.io/vast/docs/understand-vast/actor-mod...</a> (sorry for the incompleteness, we're in migration mode from the old docs, but this page is summarizing the benefits of CAF for us best)<p>- Good general actor model background: <a href="http://dist-prog-book.com/chapter/3/message-passing.html#why-the-actor-model" rel="nofollow">http://dist-prog-book.com/chapter/3/message-passing.html#why...</a>
Orbit is also the name of the always online DRM system that Ubisoft made many years ago.<p>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.<p>You can still see paths referencing Orbit in uplay, especially on the downloads: <a href="http://static3.cdn.ubi.com/orbit/launcher_installer/UbisoftGameLauncherInstaller.exe" rel="nofollow">http://static3.cdn.ubi.com/orbit/launcher_installer/UbisoftG...</a><p>Largely C++ on Windows.
I can't help but recoil from a "hello world" that pulls in an entire container ship of dependencies.<p>Especially that we already have a perfectly good, battle-hardened, and relatively lightweight implementation of Actor model with Erlang / Elixir.