Is actor the right name for this Swift feature?

I am fully aware that this topic may sound unrealistic at this point, and will probably never happen. But I still think it is worth mentioning.

I also know this naming did not come out of nowhere. Swift’s `actor` clearly comes from the broader actor model, and I am not questioning that history. I am questioning whether it was the clearest word for learning this feature in Swift.

My point is simple:

I think the word actor is not the clearest name for what this feature most importantly is in Swift. The main job of this construct is not that it "acts".
Its main job is that it isolates mutable state behind a protected boundary. That is why, from a learning point of view, a word like isolator feels more truthful to me.

For example:

actor BankAccount {

    var balance: Int = 0

    func deposit(_ amount: Int) {
        balance += amount
    }

}

What matters most here is not that BankAccount is “acting”.
What matters is that balance is isolated and protected.

If the syntax had been this:

isolator BankAccount {

    var balance: Int = 0

    func deposit(_ amount: Int) {
        balance += amount
    }

}

then I think the mental model would be more immediate.

The name actor can easily make people think of:

  • something active

  • something doing work

  • something like a worker, queue, or thread-like entity

But the important idea Swift wants us to learn is really:

  • this is an isolation boundary

  • it protects mutable state

  • it is not a task

  • it is not a thread

I know the cost of changing this would be enormous, so I am not pretending this is realistic.

My point is smaller:
I think actor was not the clearest naming choice for learning and teaching Swift Concurrency, and I am curious whether others felt the same or, if it is just me.

4 Likes

The actor model originated in 1973.

IMO making up new namings for everything would confuse people more.

5 Likes

Thanks, Benedek.

I agree 100% on the historical value of the term, and I understand that Swift did not invent actor out of nowhere.

My point is a bit narrower than that.

What is puzzling me is how this feature is most naturally understood in Swift.

From my current learning experience, which I may very well be wrong about, the strongest and most immediate idea I keep running into is isolation of mutable state. That is the part that feels most fundamental in practice.

So I fully agree with the history. I am only wondering whether keeping the same historical name was important enough to outweigh clarity for learners in Swift specifically. That part is genuine curiosity on my side.

3 Likes

You're right in concluding that the word actor does not necessarily tell you that 'this object is a class of sorts where messaging is isolated, serialized, and exclusive', and that spelling like isolated async class would have been more descriptive.

The Swift community has adopted the rule that we don't invent new words for things which already exist and we try not to create new words even if the word we are looking for is obscure. It is no surprise that software engineers enjoy specificity and accuracy even on a purely linguistic level -- and thus not reïventing the wheel.

Keeping that in mind, the question then becomes, "Was the term Actor appropriate in 1973." and the answer to that could be, no; however, I find that the word does metaphorically describe what is happening, the actor doesn't just 'do' an action immediately, it has a queue (script) of actions that it executes, while talking to other actors (on its metaphorical stage) and respecting their boundaries. They're all 'performers'

Regardless, as you have pointed out, this is the term that was chosen and it won't be changing.

I think in the future we'd still choose the same term because it is not egregious enough or too much of a departure from sensibility. With that said, your point, that I think you are making, "is this good for new users" will continue to be discussed on future terms.

I was there when it was discussed if an Actor should be a protocol on a class class MyActor: Actor or it's own thing actor MyActor, and it was understood at the time, from my memory, that the term Actor was interesting, but not volatile.

These debates come up so frequently that I have full faith that Swift community will continue to have big enough debates to answer these questions before they get out to the public.

Your insight is definitely valuable. Thank you for that!

5 Likes

Wow, austintatious,

Thank you for this very insightful answer.

The metaphor really clicked for me. Thinking of an actor as a performer on a stage honestly never crossed my mind while looking at Xcode. That was simply not where my mind was going.

Most of the learning material I came across kept emphasizing isolation, so that is the mental model I kept building again and again. I was not seeing the theatrical side of the word at all.

Your point about the serial executor being like the actor’s script or ordered set of actions made a lot of sense to me. That framing helped connect the term to the behavior in a way I had not seen before.

I had my fair share of wrestling with the term actor up to this point, and it is a bit funny that even Apple explanations often lean on metaphors like islands and isolation, and most educational material seems to follow the same tone. So naturally that became the dominant interpretation in my head.

Really, thank you for clearing that up.

4 Likes

’m pretty new to this forum, but I think you make a really good point.

I also felt that “actor” isn’t the clearest name for what the feature actually does in Swift. The core idea isn’t that it “acts” — it’s that it isolates and protects mutable state. Something like “isolator” would have made the mental model click much faster for beginners.

The name “actor” often makes people imagine workers, threads, or active processes, when the main benefit is the isolation boundary.

Curious if others felt the same confusion when learning it.

2 Likes

I mean, it does also very much do the other stuff. Making an actor and running something on it is a reasonable way to request a worker thread from the underlying runtime.

This reminds me of a thought experiment I did in the early 2010s: what would change if we had a Main Lock instead of a Main Thread? There's some interesting questions about efficiency, thread-specific data, etc, but in general my conclusion was that not much changes. "Thing that does work" and "mutual exclusion context" are surprisingly interchangeable in most ways.

3 Likes

I am thinking about it in last two days constantly.
What austintatious said was very interesting. The metaphor really stayed with me:

If you think about it, each actor on the stage has its own personality, which maps nicely to its internal state, or the vars inside it and their func (or functionality). And behind it, there is a serial executor, which acts like the sequence of things this actor will do.

Also we have this main chareter which is MainActor and it’s the main face of the play.

To me, the hardest part was taking my programmer mindset out of Xcode and trying to think about an actual theater stage. Because as long as you stay in that mindset, you always think about things like process, queue, task, job, and thread. Your mind never naturally goes to something like Joey Tribbiani.

Another point is that most of the learning materials push the discussion toward islands, isolation, docks, and chickens. Also, usually you do not see much talk about the serial executor behind each actor, probably because we do not create it manually and it is something automatic. All of this pushes your mindset in a very specific direction.

So if you are coming from GCD and learning concurrency from the old model baggage, I honestly did not find the word actor helpful at all.

But in all seriousness, austintatious’s explanation of the metaphor behind this word was beautifully done. I wish there was more of that out there, and I am happy that I started talking about it.

The Swift community is really great here.

1 Like

This would have been great. I find that people avoid actors because the name is unfamiliar, advanced sounding, and doesn't really encapsulate what it does, as most programmers are completely unfamiliar with the prior art of "Actor model." I think Swift concurrency really failed in naming in other ways as well, including "nonisolated", which is a non-word and should have been spelled in the positive/inclusive (e.g. all or any).

1 Like