# \[ANN\] YAActL 0.2, Yet Another Actor Library (built in Julia)

**URL:** <https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637>\
**Category:** Package Announcements\
**Tags:** multithreading, concurrency, actors\
**Created:** [October 19, 2020, 4:04pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637 "2020-10-19T16:04:28Z")\
**Posts on this page:** 1\
**Showing post:** 31

<div class="post-metadata">

**Author:** ![tisztamo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tisztamo/32/16200_2.png) [@tisztamo](https://discourse.julialang.org/u/tisztamo)\
**Post date:** [November 8, 2020, 8:54pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/31 "2020-11-08T20:54:45Z")

</div>

Thanks for the inviation! (I am also working on an actor system called [Circo](https://github.com/Circo-dev/Circo), yet to be announced)

> [@pbayer](#):
>
> We may use this name in the future if we have something more mature.

I agree that this is not the time to name a specific implementation as “the” Julia actor library. On the other hand, it would be very nice to have an interface defined that allows actor-level compatibility between implementations. Not sure if that interface should be called Actors.jl, AbstractActors.jl, ActorInterface.jl (see [ArrayInterface.jl](https://github.com/SciML/ArrayInterface.jl) ) or something else.

It is not easy to define that interface, because the actor model has variations with different semantics. E.g. as I understand, in YAActL.jl actors are a bit like processes, e.g. `YAActL.receive!` is a blocking operation, which is convenient, but implementing it in this way seems to be very tricky when the underlying implementation does not map actors and Julia tasks one-to-one.

The paper [43 Years of Actors: A Taxonomy of Actor Models and Their Key Properties](http://soft.vub.ac.be/Publications/2016/vub-soft-tr-16-11.pdf) seems like a good start to better understand the history and scale of actor models. It defines four classes: Classic Actors, Active Objects, Asynchronously Communicating Processes (like Erlang, not the CSP model of concurrency) and Communicating Event-Loops. I think that the other three are more or less extensions of the classic model, minus the behaviour change.

Defining a minimalistic interface for the classic model seems like a good start. What do you think?

---

_[View the full topic](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637)._