Actor system for the JVM developed by Electronic Arts

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

InfluxDB - Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
www.influxdata.com
featured
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com
featured
  • akka-kotlin

    Some experiments with using Kotlin coroutines, channels and suspendable functions in working with Akka actors

  • It's an interesting idea; not having to stash messages in the actor implementation when doing an async call. I did a little experiment what that could look like using Akka and kotlin suspend functions https://github.com/joost-de-vries/akka-kotlin

  • Orbit

    Orbit - Virtual actor framework for building distributed systems (by orbit)

  • > I can't help but recoil from a "hello world" that pulls in an entire container ship of dependencies.

    Where do you see the list of dependencies? Seems to me to be the ones defined at https://github.com/orbit/orbit/blob/233956001f1206ccbfde72ef..., is that correct? Doesn't look like "an entire container ship" but maybe the NPM madness have ruined me.

    > Especially that we already have a perfectly good, battle-hardened, and relatively lightweight implementation of Actor model with Erlang / Elixir.

    Yeah, if you're already using Erland or Elixir, why don't you go with that instead? This seems to be for the JVM, so one could assume that the ones who want to use this, is already invested heavily in the JVM ecosystem (which as far as I know, EA is when it comes to backend servers).

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • dapr

    Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.

  • The OSS project I work on, Dapr (Distributed Application Runtime - an incubated CNCF project) implements the virtual actor pattern if anyone is interested.

    https://docs.dapr.io/developing-applications/building-blocks...

    https://github.com/dapr/dapr

  • ratatoskr

    Lightweight virtual actors for node.js

  • Rosette

    Reflective actor-based language (by leithaus)

  • C++ Actor Framework

    An Open Source Implementation of the Actor Model in C++

  • 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.

    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.

    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).

    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.

    Resources:

    - CAF: https://github.com/actor-framework/actor-framework

    - VAST: https://tenzir.github.io/vast/docs/understand-vast/actor-mod... (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)

    - Good general actor model background: http://dist-prog-book.com/chapter/3/message-passing.html#why...

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts

  • Recommended method for parallelism in Julia

    1 project | /r/Julia | 7 Apr 2021
  • SObjectizer Tales - 27. Design ideas

    1 project | dev.to | 11 Apr 2024
  • SObjectizer Tales - 26. Dispatcher selection

    2 projects | dev.to | 4 Apr 2024
  • SObjectizer Tales - 23. Mutable messages

    1 project | dev.to | 14 Mar 2024
  • Spawn: A New Approach to Actors

    1 project | news.ycombinator.com | 13 Dec 2023