Any program that has at least one concurrent task that runs on a thread (naturally they’ll be more than one) is a perfect reason to switch to Actor programming model.
Even a simple print() function can see performance boost from running on a 2nd core. There is a lot of backround work to print text (parsing font metrics, indexing screen buffers, preparing scene graphs etc) and its really inefficient to block your main application while doing all this work while background cores sit idle. Yet most programmers dont know about this performance boost. Sad state of our education and the industry.
You need synchronization semantics one way or another. Even in actor systems, "send" is not magic. At minimum you need publication of the message into a mailbox with the right visibility guarantees, which means some combination of atomic ops, cache coherence traffic, and scheduler interaction. If the mailbox is cross-thread, fencing or equivalent ordering costs are part of the deal. Copying is a separate question: some systems copy eagerly, some pass pointers to immutable/refcounted data, some do small-object optimization, some rely on per-process heaps so "copy" is also a GC boundary decision.
The reason people tolerate message passing is that the costs are more legible. You pay per message, but you often avoid shared mutable state, lock convoying, and the weird tail latencies that come from many heaps or stacks aging badly under load. Fragmentation is less about one message being cheaper than one fence. It is more that at very high concurrency, memory layout failures become systemic. A benchmark showing cheap fibers on day one is not very informative if the real service runs for weeks and the allocator starts looking like modern art.
So no, I would not claim actor messaging is generally cheaper than fragmented memory in a local micro sense. I am saying it can be cheaper than the whole failure mode of "millions of stateful concurrent entities plus ad hoc sharing plus optimistic benchmarks." Different comparison.
I've no idea what the majority of programmers know or do not know about, but async logging isn't unknown and is supported by libraries like Log4j.
I always understood that if you give a thread to each actor you get the "active object" design pattern.
There are lots of problems where I wouldn't recommend fibers though
https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/CAF...
and
https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/CAC...
This will certainly speak to some people taking part in some of the more controversial discussions taking place on HN recently, to put it mildly.
Apparently it's still considered experimental (even though Google uses it in production) so it's not in the User Manual. There's this: https://github.com/sbcl/sbcl/blob/master/doc/internals-notes...
Fully awesome. No problems. A few paren issues, buit it seemed to not really struggle really. It produced working code. Was also really good at analyzing the lem codebase as well.
I even had it write an agentic coding tool in Common Lisp using the RLM ideas: https://alexzhang13.github.io/blog/2025/rlm/
Lisp is a natural fit for this kind of thing. And it worked well.
(I also suspect if parens were really a problem... there's room here for MCP or other tooling to help. Basically paredit but for agents)