Actors 101

[vns]

@crontab

Task { } and Task.detached { } can be viewed as the same thing even despite subtle difference and even though someone would call the former "concurrency" and the latter "parallelism".

The closest to parallelism is TaskGroup, yet even there it is not guaranteed. The only difference between Task and Task.detached is the first one by default inherits priority and actor context, while detached does not. Neither of them can be thought of as a parallel execution.

@crontab

In fact the original argument here is around "actors are these cool new thingies that you should use by default" is a result of people taking concurrency as not parallelism. But anyway we are going in circles here, let's see where this "actor by default" is going. (Another OOP-like disaster if you ask me.)

I think that’s a completely wrong take from statements on higher actors utilization. But let’s go one-by-one:

1. There is a widely accepted terminology of concurrent and parallel execution, they are not the same, and we rarely write parallel code in day-to-day programming.
2. Actors not a new thing in CS, they have been around for decades, and stayed there.
3. Same applies to OOP: we can hate every bit of it and say it produces bad code, but majority of widely adopted languages are object-oriented.
4. Problem not in OOP as paradigm, but in how it is applied (mostly due to the lack of understanding, probably). Well-written code can be good with any paradigm, and can be trash using the same one.
5. Finally, and most importantly — nobody here says to use actors by default. It would be insanity to blindly and unreasonably throw actor in every use case. I don’t suggest to use hammer for painting. But as concurrency building blocks they are good. If you don’t use them where they might help, you’ll never know when to use them. We have actors for a few years now, and it is still considered to be something alien and untrustworthy by many. I did the same thing: have avoided actors in majority of the code. Then, when I have had a clear case for actors and tried to apply them, I have failed in design because of lack of understanding.

That’s why I say that since we have actors model in the language, and the model suggests that everything is an actor, when we write concurrent code, we would be better utilizing them more than we think, rather then restrict to a few places. We shouldn’t reach for them first in every situation, but if we question or consider "will actor fit in there?", then give it a shot. You’ll then have much better picture of what actors are, what they good for, and how to use them effectively. No theory would teach that, but theory is an important background, a direction.