May 30, 2026
Empty box, full-blown drama
Stateless Actors
Coders are fighting over whether an "empty" helper is genius or totally pointless
TLDR: The article says a Swift actor can still be useful even without holding data, mainly to keep work safe and off the main app thread. Commenters were split between calling that overcomplicated busywork, arguing it isn’t truly stateless at all, and cracking jokes that stole the show.
A deceptively nerdy question — can a helper object with no stored data at all still be useful? — turned into a full-on comment-section scuffle. The article argues that in Swift, these "actors" can still earn their keep by being easy to pass around safely and by keeping heavy work, like decoding web data, off your phone’s main screen-updating lane. But the author also throws cold water on the idea: these helpers can be awkward with shared rules, force extra safety checks, and may accidentally make work happen one at a time, which is the exact opposite of what many people want from background tasks.
And the community? Oh, they came in swinging. One camp basically yelled, "This is just the same race-condition mess with extra boilerplate", arguing that wrapping code in fancy protective bubbles doesn’t magically fix bad design. Another commenter pulled the ultimate technical plot twist, insisting the whole premise is wrong because in Swift there’s no such thing as a truly stateless actor anyway — every one of them secretly carries a built-in property under the hood. Then, because no internet debate is complete without a drive-by joke, someone barged in with a gag about APTs — as in cyberattack groups, not programming helpers — and instantly changed the vibe from philosophy seminar to comment-thread comedy club.
So yes, the article is about code structure. But the real show is the reaction: is this a smart future-proofing move, an overengineered slowdown, or just a fancy empty box with a label on it?
Key Points
- •The article argues that stateless actors in Swift can still be useful, even though actors are primarily associated with protecting mutable state.
- •A stateless `NetworkClient` actor can provide sendability and keep synchronous work such as JSON decoding off the main thread.
- •Using actors introduces trade-offs, including protocol isolation issues and stricter requirements for `Sendable` inputs and outputs.
- •A `struct` with an `@concurrent` method is presented as an alternative that can integrate more easily with protocols and allows concurrent synchronous work.
- •The article argues that custom global actors like `BackgroundActor` serialize work and can create type-system coupling that is difficult to unwind later.