-
I don't think this question was specifically addressed in the docs. But where most of our project might use async/await - migrations to a new programming model is a hugely expensive process. What motivations/major benefits are there to consider this migration? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Actors present a different programming model than Tasks, are a more natural fit for some kinds of applications. Actor programs are typically free of locks, and most synchronization is managed by the runtime. If you find yourself designing your application as a bunch of state machines passing messages between themselves (typical for most distributed protocols) then Actors present a more natural way of mapping those state machines to code. I'd recommend that you use actors only if it simplifies your code. Make this decision early (before writing your code) so that there is no migration overhead. If you already have Tasks code that you're happy with, then no need to migrate. |
Beta Was this translation helpful? Give feedback.
-
Thanks @akashlal |
Beta Was this translation helpful? Give feedback.
Actors present a different programming model than Tasks, are a more natural fit for some kinds of applications. Actor programs are typically free of locks, and most synchronization is managed by the runtime. If you find yourself designing your application as a bunch of state machines passing messages between themselves (typical for most distributed protocols) then Actors present a more natural way of mapping those state machines to code.
I'd recommend that you use actors only if it simplifies your code. Make this decision early (before writing your code) so that there is no migration overhead. If you already have Tasks code that you're happy with, then no need to migrate.