Exploring Akka Typed
•Download as PPTX, PDF•
0 likes•100 views
This is the second presentation for a Dublin Scala Meetup comparing ZIO and Akka Typed. We did this by implementing a simple partitioned work queue with back pressure with both approaches. https://www.meetup.com/Dublin-Scala-users-group/events/265900154/ https://github.com/IainHull/akka-partition-queue
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Exploring Akka Typed
- 1. Exploring Akka Typed a partitioned work queue with back pressure #DubScala @iainhull
- 2. No more Any => Unit • Actor messages are typed • Actor behavior is a value • All state is immutable by default • Reduces but does not eliminate side effects #DubScala @iainhull
- 3. Actors are Easy • Operations are atomic and isolated (cannot deadlock) • Actors are cheep • Distributed by default #DubScala @iainhull
- 4. Actors are Hard • Concurrency assembly code • Race conditions everywhere #DubScala @iainhull
- 5. Partitioned Work Queue with Back Pressure #DubScala @iainhull
- 18. The Good • Typesafe messages make actor code easier to read, write and test • Leverage the Scala Compiler to proves you handle all cases • Behaviors as a fold over a message stream is a nice abstraction • State machines are very easy to model • Rich eco-system • Streams • Http • Clustering • Conflict Free Replicated Datatypes • Persistence / EventSourcing #DubScala @iainhull
- 19. The Bad • Actors and futures are not as powerful as fibers • Local processing appears distributed • Makes easy problems hard #DubScala @iainhull
- 20. The Ugly • Sending messages requires side-effects • ActorContext is mutable • More imperative (less descriptive than the ZIO example) #DubScala @iainhull
Editor's Notes
- Rely on the compiler to prove you have handled all cases
- The Actor model is well understood, it provides a share nothing asynchronous message passing system
- Expand on assembly code
- Actors are modelled with behaviors Behavior is like a function from message type T to Behavior[T] Really its an opaque type, it is more like a trampoline, an interpreter takes the next message from the queue and executes the behavior. You can think of Behavior as a fold of a stream of messages The behavior companion object provides standard behaviors
- Queues parameter is the state of our actor
- Run returns the new behavior with an updated state