Comparing Swim & Akka

by Simon Crosby, on May 4, 2021 8:00:00 AM

Recently several developers have asked me to compare Swim (OSS SwimOS) with other well known Actor Systems and especially Akka, which is a widely used Actor based language.

Simply put, there are three key differences:

  1. Akka is a language and runtime, whereas Swim is a set of extensions to Java (with bindings in JS and typescript for real-time UIs) and a runtime
  2. Actors in Akka communicate via messages whereas in Swim they are universally addressable via URIs that link to their streaming APIs
  3. They have quite different approaches to state management

Web Agents in Swim are similar to Akka actors in the sense that they provide a stateful, concurrent computational model with thread-safe access to state. But Swim tries to address some deficiencies of Actor systems, specifically:

  • Akka actors are only accessible via the Actor Context. So it's impossible to reach an actor from a client that wants to observe it (eg from another application or browser).   In Swim, each Web Agent is universally addressable via a unique URI and any program (including a browser) can use this to access the state of the Web Agent.  A Swim URI is a link to a streaming API "on the web"
  • Akka actors use messages to notify other actors about state changes.  This is challenging because 
    • The sender has to know about and actively push messages to each of the recipients.  How newly "interested" actors make it onto the list of recipients is a puzzle left to the  developer
    • The receiver may waste a lot of time processing useless messages when it wakes up, before it gets to a message that is really important.  Swim applications care about the current state, not the sequence of changes that led to the current state, because a primary focus is on staying in-sync with the real world.

    Swim uses a distributed cache coherence protocol (WARP) that automatically propagates state changes of a Web Agent to all clients that have linked to it (via the streaming URI). The current state of any Web Agent is visible to any client that links to it, and state changes are automatically pushed to all clients.

These features help immensely when building applications. For example, real-time web UIs become simple to build since  JS object can continuously render the current state of a Web Agent because by simply linking to it, it will continuously stream state updates to the browser. It also makes application composition as trivial as object composition in an OOP system. Implementing URI addressability, adding a protocol to propagate state changes and supporting multiple concurrent read access to an actor is pretty complicated to do with Akka.

Finally, Swim applications, while currently Java based, rely only on the JVM (we use Graal) and the Swim platform, which is being re-written in Rust.  Many application DSLs are possible so you will eventually be able to use your favorite DSL and get all the power of Swim.

Topics:swimOSweb agentsjavaAkkaActor Paradigm