@rmacdonaldsmith the core idea of actor model is that what's excecuted inside actor scope is synchronous, while actors themselfs are dispatched in asynchronous manner. Some problem arises, when you try to apply this concept to work with long-running request/response actions and interop with existing async APIs used in other parts of .NET framework
also, the third reason, C# people are used to program with async/await, since Microsoft was highly encouraging this approach in recent years - it's hard to fight with existing habits
that beeing said, we are looking into how to support async await w/o confusing anyone. and we are leaning towards supporting it in the same way as sync messages work.. so if a message comes in and you want to go async. no more messages will be processed until that task has completed.. so sticking with the same semantics as for sync, but you can await async IO ops or Actor Ask w/o blocking any threads... so you get a synchronous flow using await, with nonblocking io
Please correct me if I'm wrong: does this mean that we want to kind of "block" an actor for the time of an internal I/O operation but to do it in such a manner that no system resources will be blocked? I'm just asking to make sure that I get it right.
@Horusiath@rogeralsing thanks for the reply! Yes, I understand that stripping async/await may put others off. I really like Rogers idea of keeping the Actor Model sematics; you get the async that you want inside your actor but you are not messing with the overall idea of the actor model.