@WhatWouldBukowskiDo: But that has nothing to do with actors. You can do the same coarse-grained API-design with locks or synchronized methods too. Like I said, actors may expose more parallellism (because they run on their own lightweight thread), but they don't improve correctness. At the end of the day it's just locks in a different form.
I'd also somewhat disagree with the API suggestion, actually.
In a single-threaded scenario it's generally regarded better to have a few generic methods that can be easily composed to do fifty things, than have fifty "big" methods (i.e. the API should be "minimal and complete"). It's only when you bring in locking that you need to specialize and pull things together into "bigger" methods so that you can carefully manage locking for some common tasks. That may well be the best strategy on balance when you do have to worry about locking, but it's at least worth noticing that you're going against normal guidelines for good API-design when doing so, which indicates that the concurrency model has some room to improve.
Ideally we could still use a "minimal and complete" API design that affords composability, while maintaining thread safety. This is, for example, what STM is designed to solve.