I added a new concurrent pod with support for atomics which was something I really needed our commercial work.

The big question is does Actor and company (ActorPool and Future) belong in sys or concurrent?

I think it actually might make sense to move Actor out of the core and into concurrent. For things like JarDist, moving it out would shave lots of KB's from the required core library.

However there are a couple issues:

• I believe sleep has to be available from the core, but we can move to Env
• Actor.locals might be tricky not having in the core, but I think it can move
• Any eventual async IO might be tricky if we don't have things like Future in sys

What do people say? Move Actor APIs to concurrent or leave them in sys?

The concurrent pod sounds like a logical place for actors.

I like that.

And I like Sleep being in the core somewhere since it's so commonly use.

I remember wondering where it was the first time I needed it.

Promoted to ticket #977 and assigned to brian

Move Actor, Future, and ActorPool APIs to concurrent

Renamed from New concurrent pod to New concurrent pod (move Actor)

Ticket cancelled

After a little more thought, I am not sure it is worth all the work to move Actor API. Given that we don't know how actors will fit into JavaScript web workers or async IO I'm sort of feeling the safest path is to just leave it in sys.

Sad. I was hoping to see this one. Leaving them in sys advocates Actors as the One True Way of concurrency, and as we all know, no such thing exists.

we don't know how actors will fit into JavaScript web workers

This would actually be a vote for moving to concurrent I think - then we can replace wholesale the concurrent APIs available in JavaScript - since its highly unlikely they will look anything alike (at least in the near future).

Regardless - I do think Actor makes the most sense in concurrent - but I haven't dug into what would actually be involved in moving it - just need to make sure we assess this before we stamp 1.0.

Ticket reopened

I am going to take another look at this tomorrow.

Right now I'm planning on doing a new build this week which has all the planned breaking changes behind us.

Ticket resolved in 1.0.53

The Actor, ActorPool, and Future classes have been moved from sys to concurrent.

In general the only fix required to your code is to add a dependency and using statement for concurrent.