It's a common but wrong belief that "no shared mutable state" means no race conditions or other concurrency errors. Anyone who has written code with an actor-style design knows this isn't the case - message passing changes the kinds of bugs you get but doesn't magically make concurrent coding bug free or easy.
I'm really unconvinced by this design decision, for the reasons stated in the article but also the apparent belief that it's always and everywhere a better way to use message passing.
08/28/2019, 1:36 PM
Hmm. I didn't say that message passing magically makes concurrency easy or bug free, but I do not see how can there be race conditions without shared mutable state. Can you explain further ?
08/29/2019, 7:31 AM
No, I know, I was more making a general reflection about Kotlin/Native's design decision.
With actors it's easy to end up either with circular deadlock (A sends a message to B and waits for a response, B sends to C, C sends to A, stop), and/or you can end up with backpressure problems where different parts of the system run at different speeds and overflow their message queues. All these issues have a habit of showing up only in certain timing conditions or if things only happen in very specific orderings, especially because different parts of the system can post messages to a central actor in different orders depending on execution speed.
Of course you can define 'race condition' to mean specifically 'data race' but I think most programmers understand it as more like 'my program sometimes breaks depending on obscure differences in timing' and actors can still have that problem