[jwstarr]

We use them both implicitly (underlying Akka Streams) and explicitly (both classic untyped actors and typed actors).

For the explicit actors, we use them to model state machines around I/O (e.g. stateful protocols). I've found that the application area is fairly niche, as many patterns of async work are clearer through queues, futures, or streams. The use of actors is insulated from the rest of the application code through interfaces that use futures or streams. But, internally, if you have to manage complex state where events can occur at any time and a mail-box like/internal queue is sufficient, then they tend to be easy to understand... once the initial ramp-up period is over.

Additionally, I've found them to require very little maintenance as developers tend to get to 100% _flow_ test coverage without a lot of difficulty.

[lostintangent]

Are you using Akka for your explicit actors as well?

And could you share the distinction between typed and untyped actors? Is that related to how the caller addresses/accesses methods on that actor?

[jwstarr]

Yes, we use Akka for all the actors.

Akka has two types of actors: typed and untyped. Typed actors allow the compiler to type check messages, while untyped (or classic actors) perform runtime checking. This also means references to actors can be typed, so if you have multiple implementations of actors that implement the same protocol, you can substitute between the different actors and verify the protocol at compile time.

https://doc.akka.io/docs/akka/current/typed/from-classic.htm...

I had played with Erlang before using Scala/Akka, so untyped actors were a familiar experience. My team decided to use typed actors going forward after an Akka version update since that seems to be the strategic direction of Akka (and it does help to have the compiler complain if we try sending a message that the actor doesn't understand).

[lostintangent]

Ah! That makes total sense. Thanks so much for that additional context.