# \[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:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![pbayer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbayer/32/11675_2.png) [@pbayer](https://discourse.julialang.org/u/pbayer)\
**Post date:** [October 19, 2020, 4:04pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/1 "2020-10-19T16:04:28Z")

</div>

I am happy to announce [YAActL](https://github.com/pbayer/YAActL.jl), a new actor library for concurrent programming in Julia.

> An Actor is a computational entity that, in response to a message it receives, can concurrently:
> 
> - send a finite number of messages to other actors;
> - create a finite number of new actors;
> - designate the behavior to be used for the next message it receives.

See: The [Actor Model](https://en.wikipedia.org/wiki/Actor_model) on Wikipedia.

## `YAActL` is

- available in the Julia registry,
- based on the Actor model,
- builds on Julia’s multiple dispatch and
- `Task`, `Channel` and `Threads.@spawn` and
- has also a little support for `Distributed`.
- Actors follow a messaging protocol for dispatching their behavior functions and
- got an Erlang/OTP-inspired API.
- `YAActL` has a [nice documentation](https://pbayer.github.io/YAActL.jl/stable/).

Since it is quite new,

- a supervisory tree and
- a generic server behavior

are not yet implemented and will come in the next steps.

I think actors are a useful addition to Julia’s ecosystem. Please look at `YAActL` and tell me what you think. I would be happy if you try it out and find it useful.

I hope to get some feedback from you, help and/or collaborators sharing my excitement about actors.

---

<div class="post-metadata">

**Author:** ![datnamer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/datnamer/32/3471_2.png) [@datnamer](https://discourse.julialang.org/u/datnamer)\
**Post date:** [October 19, 2020, 8:06pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/2 "2020-10-19T20:06:01Z")

</div>

This is great!

Have you seen the [Swift concurrency manifesto](https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782) ? Might have some interesting ideas for this space. Also leans heavily on actor stuff

---

<div class="post-metadata">

**Author:** ![pbayer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbayer/32/11675_2.png) [@pbayer](https://discourse.julialang.org/u/pbayer)\
**Post date:** [October 20, 2020, 7:35am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/3 "2020-10-20T07:35:26Z")

</div>

> [@datnamer](#):
>
> the [Swift concurrency manifesto](https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782)

Thank you for the link. The paper is interesting and has a lot of references. I’m surprised to hear that Swift doesn’t have something like async/wait as basic concurrency primitives (the paper is from 2017).

But I share very much the general direction of the paper:

> We are focusing on task based concurrency, not data parallelism.

There **should be more work done on concurrency** , understood as “composition of independently executing processes” (see: Rob Pike’s presentation [Concurrency is not parallelism](https://blog.golang.org/waza-talk))

Fortunately Julia has primitives for [asynchronous programming](https://docs.julialang.org/en/v1/manual/asynchronous-programming/#man-asynchronous): `Task`, `@async`, `Channel`, `Threads.@spawn` and the like. But working with those directly sometimes gets a little clunky.

Therefore I think that an API could be helpful. I don’t know if `YAActL` is the best approach, but it builds on ideas from Erlang/OTP as something time-tested. And you **can do the stuff** Rob Pike talks about, quite well with it.

There are other ideas around: from Akka/Scala, Go, Pony … some cited in the manifesto. **Let’s play with them!**

---

<div class="post-metadata">

**Author:** ![oschulz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oschulz/32/2998_2.png) [@oschulz](https://discourse.julialang.org/u/oschulz)\
**Post date:** [October 27, 2020, 3:20pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/4 "2020-10-27T15:20:57Z")

</div>

Btw, I created and registered Actors.jl ([https://github.com/oschulz/Actors.jl](https://github.com/oschulz/Actors.jl)) a long time ago, but it it never got very far (it was before Julia had multi-threadable tasks).

If someone is interested, the package name is up for grabs (the last version was pre-Julia-v1.0), it could be replaced by a new actor package under the same name. Just let me know.

---

<div class="post-metadata">

**Author:** ![pbayer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbayer/32/11675_2.png) [@pbayer](https://discourse.julialang.org/u/pbayer)\
**Post date:** [October 27, 2020, 4:01pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/5 "2020-10-27T16:01:50Z")

</div>

Do you plan to restart with working on actors?. What do you think of `YAActL`?

There is also [Richard Palethorpe / Actors.jl · GitLab](https://gitlab.com/Palethorpe/Actors.jl), but doesn’t seem to be active now.

Other languages have [several actor libraries and frameworks](https://en.wikipedia.org/wiki/Actor_model#Actor_libraries_and_frameworks). and many of them seem to be based on community efforts (e.g. Rust’s [Actix](https://github.com/actix/actix)). I think that a community effort for a Julian actor library should take `Actors.jl`.

Maybe/hopefully `YAActL.jl` will evolve to it. After learning more about Erlang I plan to implement an actor supervision tree next. I welcome any help.

---

<div class="post-metadata">

**Author:** ![oschulz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oschulz/32/2998_2.png) [@oschulz](https://discourse.julialang.org/u/oschulz)\
**Post date:** [October 27, 2020, 6:29pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/6 "2020-10-27T18:29:17Z")

</div>

There’s also Luvvy [Luvvy - Use Actors liberally for robust, highly parallel Julia code (prototype)](https://discourse.julialang.org/t/luvvy-use-actors-liberally-for-robust-highly-parallel-julia-code-prototype/30086) .

> I think that a community effort for a Julian actor library should take `Actors.jl` .

I fully agree. Personally, I like the actor model very much, but won’t be able to do anything in that direction in the foreseeable future. So if there’s a community push for a nice fully-fledged actors package I’ll be glad to let them have Actors.jl.

---

<div class="post-metadata">

**Author:** ![richiejp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/richiejp/32/19236_2.png) [@richiejp](https://discourse.julialang.org/u/richiejp)\
**Post date:** [October 28, 2020, 6:51am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/7 "2020-10-28T06:51:42Z")

</div>

Actors.jl used to be Luvvy and Luvvy is now a web framework I only experimented with. I’m happy for the community to take Actors.jl if their is some momentum building around another project of course. OTOH there are a bunch of very different paths you can take with an Actor model library, so perhaps projects are more correct to use names like Actix or Akka.

I do think Julia is a really great fit for the actor model, but there are some low level issues to sort out around channels and Tasks (well, at least there were, I haven’t had much time with Julia recently). Also I wonder weather Distributed could essentially have actor like features added to it?

---

<div class="post-metadata">

**Author:** ![pbayer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbayer/32/11675_2.png) [@pbayer](https://discourse.julialang.org/u/pbayer)\
**Post date:** [October 28, 2020, 7:50am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/8 "2020-10-28T07:50:42Z")

</div>

> [@richiejp](#):
>
> OTOH there are a bunch of very different paths you can take with an Actor model library

There are some design decisions to take, amongst them:

- should it build on Julia’s primitives (task and Channel)?
- how is the message processing done (e.g pattern matching, multiple dispatch …)?
- should it be transparent between `Threads` and `Distributed`?
- should it implement behaviors and how?
- how should actors be isolated from one another?
- …

I think many of those considerations are well described in Joe Armstrong’s dissertation: [Making reliable distributed systems in the presence of software errors](https://erlang.org/download/armstrong_thesis_2003.pdf).

Armstrong gives a reason for doing it at all (p. 19):

> In Concurrency Oriented Programming the concurrent structure of the program should follow the concurrent structure of the application. It is particularly suited to programming applications which model or interact with the real world. …

Therefore I think, the design decisions in an actor library must be taken such to facilitate and to give good support for concurrency.

> [@richiejp](#):
>
> Julia is a really great fit for the actor model

I agree!

---

<div class="post-metadata">

**Author:** ![richiejp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/richiejp/32/19236_2.png) [@richiejp](https://discourse.julialang.org/u/richiejp)\
**Post date:** [October 28, 2020, 8:39am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/9 "2020-10-28T08:39:27Z")

</div>

> should it build on Julia’s primitives (task and Channel)?

I can answer fairly certainly: yes with one exception.

I think it is acceptable, in fact necessary, to temporarily implement an alternative Channel (like I was considering using liburcu’s queue which I did in another Actors library I created [libactors; Actor model and message passing in C with Userland RCU](https://richiejp.com/rcu-actors)) to experiment with disruptive changes. However this should be upstreamed to Julia’s core where it will benefit a lot more than just actors.

I guess for playing with alternate tasks/thread models you would have to fork Julia itself as there are some locks dotted around in the C code that need to be taken care of. However in any case you don’t want to be carrying those changes forever in a third party library if the core library has something like Task deeply wired into it.

> how is the message processing done

Well my library abuses multiple dispatch, but also allows pattern matching. You can definitely have both here, it’s just a case of giving the user hooks lower into the stack.

[https://palethorpe.gitlab.io/Actors.jl/reference/#Actors.listen!-Tuple{Scene}](https://palethorpe.gitlab.io/Actors.jl/reference/#Actors.listen!-Tuple%7BScene%7D)

Implementing Pony style behaviors should be possible, but I suppose it requires some fancy code generation which might make it a little magical.

> should it be transparent between `Threads` and `Distributed` ?  
> how should actors be isolated from one another?

Now these are really difficult ones! Utimately running on a different CPU core with shared memory and running different computers are very different things. It might not be a good idea to create the illusion they are the same thing.

I guess this list could be greatly extended. I still have some ideas about chaining messages to control nondeterminism, logging and such which I haven’t had chance to touch.

> I think many of those considerations are well described in Joe Armstrong’s dissertation: [Making reliable distributed systems in the presence of software errors](https://erlang.org/download/armstrong_thesis_2003.pdf).

Thanks, I will add that to my reading list.

---

<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:** [October 28, 2020, 8:58am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/10 "2020-10-28T08:58:34Z")

</div>

> [@richiejp](#):
>
> Utimately running on a different CPU core with shared memory and running different computers are very different things. It might not be a good idea to create the illusion they are the same thing.

Location transparency is a key feature of the actor model. It allows the programmer to build the software out of small concurrent pieces (actors) without worrying about hardware. And it allows the runtime to optimize actor placement using knowledge about actual hardware.

Without location transparency, I do not see much gain with actors over async/threads/distributed.

---

<div class="post-metadata">

**Author:** ![pbayer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbayer/32/11675_2.png) [@pbayer](https://discourse.julialang.org/u/pbayer)\
**Post date:** [October 28, 2020, 9:21am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/11 "2020-10-28T09:21:21Z")

</div>

Location transparency enables non-local error-handling. From Armstrong’s dissertation (p. 40):

> When we make a fault-tolerant system we need at least two physically separated computers. Using a single computer will not work, if it crashes, all is lost. The simplest fault-tolerant system we can imagine has exactly two computers, if one computer crashes, then the other computer should take over what the first computer was doing. In this simple situation even the software for fault-recovery must be non-local; the error occurs on the first machine, but is corrected by software running on the second machine.

On the other hand local computations (multi-threading) are much more efficient for lightweight tasks. Therefore we must be able to decide if an actor should run locally or remotely but then communication between them must be transparent.

---

<div class="post-metadata">

**Author:** ![richiejp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/richiejp/32/19236_2.png) [@richiejp](https://discourse.julialang.org/u/richiejp)\
**Post date:** [October 28, 2020, 11:52am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/12 "2020-10-28T11:52:52Z")

</div>

I think there is more to the actor model than just location transparency, but maybe for practical usage it is what really matters. At any rate, you have to decide what happens when a user passes a pointer to mutable data in a message. If you want true transparency then you have to make all messages immutable or copy-on-write and prevent the user from passing references to local resources.

Frankly you can’t actually enforce that and there will be some crazy user (the cluster manager for a start) who wants to pass file descriptors (for example) in messages if they know the other actor is local to the machine or pointers/references if it is in the same thread. They may also want to create actors which are as local to the current one as possible or the opposite which is perfectly valid for performance or reliability respectively.

All I am saying here is that you can decide to have an API which allows the user to find out the locality of another actor and take advantage of it or you can not. On the happy path the locality of other actors doesn’t matter, so in that case you have full transparency, which I am not against.

> Therefore we must be able to decide if an actor should run locally or remotely but then communication between them must be transparent.

Yes, but additionally you perhaps want a way to mark message types (or any type) as being local only or maybe requiring some processing before being transmitted remotely. For example if it contains local timestamps, these may need to be converted, which could be done transparently at a high level, but the user needs some way of implementing the conversion routines to make it transparent. I’m sure there is plenty of other stuff as well.

---

<div class="post-metadata">

**Author:** ![pbayer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbayer/32/11675_2.png) [@pbayer](https://discourse.julialang.org/u/pbayer)\
**Post date:** [October 28, 2020, 5:20pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/13 "2020-10-28T17:20:59Z")

</div>

> [@richiejp](#):
>
> there is more to the actor model than just location transparency

For sure, there are state-machines, servers, event-managers, agents … Actors have polymorphism and can represent all sorts of interacting concurrent entities. Location transparency is just one characteristic.

> [@richiejp](#):
>
> If you want true transparency then you have to make all messages immutable or copy-on-write

This is what Armstrong strongly recommends. If we don’t want it in a Julian library – mostly for performance reasons –, we have to tackle some complexity as you describe.

More examples:

- if a local actor (with a local channel) has a request from a remote actor, it cannot send it its local channel (a mutable variable) for responding but has to create a remote channel and a forwarder actor to forward the response to the local channel.
- how do we handle communication between (local) actors each on different nodes?
- If we extend location transparency, actors from different concurrency oriented languages (COPLs) should be able to communicate. How do we handle that?

At the moment I don’t know if an API can handle all such cases. They keep popping up. If not – maybe – we have to follow Armstrong’s recommendation.

---

<div class="post-metadata">

**Author:** ![Akatz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/akatz/32/15164_2.png) [@Akatz](https://discourse.julialang.org/u/Akatz)\
**Post date:** [October 30, 2020, 5:31pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/14 "2020-10-30T17:31:39Z")

</div>

Here’s an update to the swift concurrency manifesto, with the concrete plan. Leverages actors and structured concurrency :

> **[Swift Concurrency Roadmap](https://forums.swift.org/t/swift-concurrency-roadmap/41611)**
>
> A PR with this document can be found here Swift Concurrency Roadmap Our goal is to make concurrent programming in Swift convenient, efficient, and safe. This document outlines a number of proposed additions and changes to the language to...

Edit: Here’s the zoom in on actors [https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md](https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md)

---

<div class="post-metadata">

**Author:** ![pbayer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbayer/32/11675_2.png) [@pbayer](https://discourse.julialang.org/u/pbayer)\
**Post date:** [October 31, 2020, 10:08am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/15 "2020-10-31T10:08:00Z")

</div>

Very interesting. When I first saw in their proposal …

```julia
actor class BankAccount {
  private let ownerName: String
  private var balance: Double
}

```

I felt that they are missing the point. After thinking some time about it I can explain this feeling and why I think we can do better.

Basically the question is what an `Actor` should be in a programming language among the other existing language constructs like `Task`, `Function`, `Channel`, `Type`, `Class` … or what it should represent. Gul Agha wrote:

> An actor may be described by specifying:
> 
> - its mail address, to which there corresponds a sufficiently large _mail queue_; and,
> - its _behavior_, which is a function of the communication accepted.
> 
> [Gul Agha: Actors, A Model of Concurrent Computation in Distributed Systems; MIT press, 1986, p 24]

And then he gave the following picture (p. 26):

 ![Agha 3.2](https://global.discourse-cdn.com/julialang/original/3X/3/6/368d0968517e0b0cedae59f0eafe5b7de6712e27.jpeg)

An `Actor` is different from a `Task` since it has a mailbox (e.g. a `Channel`) and a behavior (a `Function` f(c) of the communication accepted). It can create `Task`s or `Actor`s. Therefore the main difference from a `Task` is that an `Actor` dispatches its behavior only after having received a message. (So far no talk about classes, data, inheritance … at all.) The next question is what happens when an Actor has processed a message. The replacement is deliberate: the actor can maintain or switch its behavior or hand over the communication to a newly created actor machine or simply stop.

The Swift proposal binds actors to objects with encapsulated functions. This may be consequential for an OO language. But …

I think that a **Julian approach** is to associate and start an `Actor` with a behavior `Function`. This returns a `Channel` representing the actor. The actor listens (as a `Task`) to its channel and dispatches its behavior with an incoming message. Then there must be functions like `become` for specifying the replacement (e.g. switching the behavior).

We have all the needed ingredients to implement that and it is more straightforward and aligned with the Actor model. This makes Julia

> [@richiejp](#):
>
> a really great fit for the actor model

Finally:

- reading such proposals in a foreign programming language is interesting since it makes one think and go back to the drawing board,
- I agree with most what they write about **basic actor isolation** but I am sceptical about their “Full Actor Isolation”. It will be interesting to see what they come up with.

---

<div class="post-metadata">

**Author:** ![richiejp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/richiejp/32/19236_2.png) [@richiejp](https://discourse.julialang.org/u/richiejp)\
**Post date:** [November 1, 2020, 10:25am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/16 "2020-11-01T10:25:41Z")

</div>

> I felt that they are missing the point

Yes, I like that you are taking this back more to the formal Actor model specified by Gul and Co. I wasn’t sure quite how far to take that so my library doesn’t have any concept of behaviors and state transitions. I’m not sure that ERlang really leverages the early research on the Actor model either.

Speaking of ERlang, I like the concept of protocols in Armstrong’s thesis. This sounds somewhat similar to idea I had which I call ‘dialogs’. Which are essentially _contracts_ specifying how one or more actors interact during a sequence of message exchanges. These could specify what state(s) an actor should be in after receiving a message, what messages it may send in response and timeouts. These would be written separately from the actors’ internal logic, so the user can specify on a high level how actors should behave separate to the implementation.

The number one issue I have had constructing actor systems is debugging the scenario where all messages stop, but I’m expecting the system to do something. Often I have a chain of actors, so it is not enough to simply expect one actor to respond to another. Then when other people come to read my code they have to piece the resulting system behavior together from the individual message handler code (unless I write a high level description).

> An `Actor` is different from a `Task` since it has a mailbox (e.g. a `Channel` ) and a behavior (a `Function` f(c) of the communication accepted).

Something else which I find interesting about this is the possibility to process messages to a single actor in parallel. Essentially once an actor has decided whether or not a message should update its behavior (or state) it may start processing the next message in parallel. It is only when a behavior change is required that it should wait for all parallel messages to finish processing before continuing. This means that you don’t need N or more actors to take advantage of N processors.

---

<div class="post-metadata">

**Author:** ![Akatz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/akatz/32/15164_2.png) [@Akatz](https://discourse.julialang.org/u/Akatz)\
**Post date:** [November 1, 2020, 5:54pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/17 "2020-11-01T17:54:11Z")

</div>

Glad you found it helpful.

You might also be interested in the ensuing discussion(s):

> **[Swift Concurrency Roadmap](https://news.ycombinator.com/item?id=24944777)**
>
> 158 points —
> 99 comments —
> rainworld —
> 5:36 PM - 30 Oct 2020

> **[\[Concurrency\] Actors & actor isolation](https://forums.swift.org/t/concurrency-actors-actor-isolation/41613/63)**
>
> Thinking about this interleaving issue at suspension points - maybe an await could throw or somehow indicate to the caller when interleaved partial task changed common state in order to refetch state or change their computation?

Also regarding actor isolation, there’s a new interesting proposal by Chris Lattner, the creator of swift, to amend the actor proposal:

> **[Pitch: Protocol-based Actor Isolation](https://forums.swift.org/t/pitch-protocol-based-actor-isolation/41677)**
>
> Hi all, I got a chance to write up some thoughts on how to address one of the major challenges with the recent actor model proposal: how do we ensure that values transferred between actors do not introduce shared mutable state. I'd appreciate...

Here are some related Julia efforts for the future regarding immutable state that may be helpful to keep in mind:

> **[GitHub - tkf/Mutabilities.jl](https://github.com/tkf/Mutabilities.jl)**
>
> Contribute to tkf/Mutabilities.jl development by creating an account on GitHub.

> <https://github.com/JuliaLang/julia/pull/31630>
>
> This is part of a larger set of overhauls I'd like to do in the 2.0 timeframe (a…long with #21912 and other things along these lines). As such this is more of a straw-man implementation to play with various ideas. I doubt any of this code will get merged as is, but should provide a place for experimentation and we may start picking off good ideas from here.
> 
> The basic concept here is that I think we're missing a heap-allocated \*immutable\* array. We have Array (mutable and dynamically sized), StaticArray (immutable and statically sized) and MArray (mutable and statically sized), but we don't really have an immutable dynamically sized array. This PR adds that.
> 
> In my ideal world, most functions would return immutable arrays. In a lot of code, it is fairly rare to require semantically mutable arrays at the highest level of the API (of course operations are internally often implemented as mutating operations) and even in a good chunk of the cases that make use of them, they are used as a performance optimization rather than a semantic necessity. 
> 
> On the other hand, having an immutability guarantee can be quite useful. For example, it would solve a lot of the performance problems around aliasing (the reason LLVM can't vectorize in a lot of cases is that it doesn't know that the output array doesn't overlap the input array - if the input array is immutable that obviously can't happen).
> 
> Immutability is also nice for higher level applications. Since views and slices are the same thing in immutable arrays, operations that would semantically be required to make copies on mutable arrays (say an AD system taking captures during the forward pass), can use views instead.
> 
> Now, the problem here of course is that sometimes you do want mutation, particularly during construction of various objects (i.e. you construct the object once by setting something to every memory location, but then it's immutable afterwards). This PR introduces the \`freeze\` function, which takes a mutable array and returns an immutable array with the same memory contents. Semantically this function is a copy, but the idea is that the compiler will be able to elide this copy in most circumstances, thus allowing immutable arrays to be constructed using mutating operations without overhead. Similarly, there is the \`melt\` function which does the opposite. Once this infrastructure is mature, it should be trivial to get either the immutable or the mutable version in a zero-overhead (after compiler optimizations) manner of any array function just by adding the appropriate freeze/melt function. The 2.0 goal would then be to actually make most array operations return the immutable versions of the array.
> 
> Another motivation here is to make it easier to write code that it generic over mutability in order to support things like XLA and other optimizing linear algebra compilers that operate on immutable tensors as their primitives. By having a well defined way to talk about mutability in the standard library, it should be easier to plug in those external implementations seamlessly.

And finally, a discussion on structured concurrency:

> <https://github.com/JuliaLang/julia/issues/33248>
>
> In julia 1.3 the threadsafe runtime for truly parallel tasks \[has arrived\](https…://julialang.org/blog/2019/07/multithreading) which will greatly increase the interest in concurrent computation in Julia's core numerical and technical computing community. For the moment, \`Threads.@spawn\` is experimental, but now is a good time to think about APIs for expressing concurrent computation in a safe and composable way with the aim to use such an API as an ecosystem gets built on top of the new functionality.
> 
> There's been a lot of recent excitement and hard work on libraries to support so-called \*structured concurrency\*, with the claim that this is fundamentally a better model for composable concurrent computation.
> 
> I'm convinced that people are onto something here and that the overall ideas are an excellent fit for the Julia language. However, there's a lot of prior art to absorb so I have started a document with the aim to do two things:
> \* Survey existing ideas and implementations
> \* Explore how these ideas fit within the Julia language and runtime.
> 
> \### \[\*\*Click here to read the WIP document\*\*\](https://github.com/JuliaLang/Juleps/blob/master/StructuredConcurrency.md)
> 
> \#### Meta note
> 
> I'm using this julep as a guinea pig to try out a go-proposals style workflow, as discussed at https://github.com/JuliaLang/julia/issues/33239. So let's try discussing this here (non-substantive procedural comments to go to the Juleps repo.

and the relevant swift proposal:

> **[\[Concurrency\] Structured concurrency](https://forums.swift.org/t/concurrency-structured-concurrency/41622/50)**
>
> Scopes are typically implicit (i.e. usually there's no handle to them) so if the nursery wasn't passed as an argument I would agree that "task scope" would be the best name for the concept. As it is though, inner closures can reference the...

---

<div class="post-metadata">

**Author:** ![pbayer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbayer/32/11675_2.png) [@pbayer](https://discourse.julialang.org/u/pbayer)\
**Post date:** [November 2, 2020, 10:13am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/18 "2020-11-02T10:13:35Z")

</div>

> [@richiejp](#):
>
> taking this back more to the formal Actor model

I find it interesting that many of those “old” ideas have not been fully exploited. Erlang was created at about the same time. So its not surprising that the behavior concept is not leveraged in it. But now we can try to exploit it.

> [@richiejp](#):
>
> I like the concept of protocols in Armstrong’s thesis

Yes, communication must be constrained so that actors can operate as state machines. `YAActL` actors follow a message protocol that can be extended by the user. The API simply is an interface to the protocol.

> [@richiejp](#):
>
> The number one issue I have had constructing actor systems is debugging

Yes debugging them is tricky. Have you noticed that the Erlang/Elixir people have graphical tools for it like Appmon, Pman, a process oriented debugger … The interesting thing is that debugging actor systems will become much more easier than debugging concurrent programs built on concurrency primitives. I think with actor monitors, ties and supervision in `YAActL` 0.3 this will already improve and be demonstrable:

> <https://github.com/JuliaActors/Actors.jl/issues/17>
>
> Basic supervision must be built right into \`Actors\`. This is described in issue …#16 . 
> 
> \## Supervision tree
> 
> The possibility to define a supervision tree in a module with actors as callback functions has to be implemented in a separate library. This will allow a user to easily build multilevel supervision trees.
> 
> \- \[x\] create \`Supervisors.jl\`,
> \- \[\] specify \`Supervisors\`,
> \- \[\] develop \`Supervisors\`.

> [@richiejp](#):
>
> the possibility to process messages to a single actor in parallel

Yes, as shown in Gul’s picture there are to ways for that: an actor can spawn tasks or it can start further actors. A typical application is a parallel server: when it receives a request, it starts another actor to handle it. Then it immediately returns to its message queue to look for the next request. An actor can also start parallel computations.

---

<div class="post-metadata">

**Author:** ![pbayer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbayer/32/11675_2.png) [@pbayer](https://discourse.julialang.org/u/pbayer)\
**Post date:** [November 2, 2020, 10:49am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/19 "2020-11-02T10:49:20Z")

</div>

> [@Akatz](#):
>
> a discussion on structured concurrency

Thank you for mentioning that. It links to [Structured Concurrency](https://github.com/JuliaLang/Juleps/blob/master/StructuredConcurrency.md). This suggests that a task must finish before its parent task finishes:

> Structured concurrency means that lifetimes of concurrent functions are cleanly nested. If coroutine `foo` launches coroutine `bar` , then `bar` must finish before `foo` finishes.
> 
> This is not structured concurrency:
> 
> [![unstructured concurrency](https://global.discourse-cdn.com/julialang/original/3X/f/a/fa0fcc8ba1e814fe3c0a0ec32b154b0b34b93188.jpeg)](https://github.com/JuliaLang/Juleps/blob/master/StructuredConcurrency_not_structured.jpeg)
> 
> This is structured concurrency:
> 
> [![structured concurrency](https://global.discourse-cdn.com/julialang/original/3X/9/7/979eadded47412b19c4f794c7eb07aa138c66921.jpeg)](https://github.com/JuliaLang/Juleps/blob/master/StructuredConcurrency_structured.jpeg)

Even if I agree with the diagnosis (go statements are harmful!), I have some reservations regarding the cure:

With actors there is no such restriction of their lifetime. An actor A may simply start another actor B and then finish. Actor B then outlives A. Supervision of B can still be done by linking B **deliberately** to other actors C and D. When one of them exits abnormally, B is taken down as well or vice versa. One of them can be made a supervisor … What I just described is Erlang/Elixir-like error handling and I feel it to be much stronger than the [libdill](http://libdill.org/structured-concurrency.html) approach.

I would suggest that we don’t take the latter too seriously (e.g. by enforcing it). Still there is the need to have powerful methods for writing fault tolerant concurrent programs. I feel that for that one can build on the Erlang approach.

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [November 2, 2020, 11:02am UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/20 "2020-11-02T11:02:17Z")

</div>

Very stupid question from me - in the Actor models is there fault tolerance?  
I ask because int he era of exascale computers there might be failures during a model run.  
Can the model continue to run and perhaps repeat the compute portion on a n actor which has not failed?

[Next page](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637.md?page=2)