<https://itnext.io/why-the-kotlin-native-memory-mo...

# feed

[salomonbrys]

https://itnext.io/why-the-kotlin-native-memory-model-cannot-hold-ae1631d80cf6

[mikehearn]

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.

[mikehearn]

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.

[salomonbrys]

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 ?

[mikehearn]

No, I know, I was more making a general reflection about Kotlin/Native's design decision.

[mikehearn]

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.

[mikehearn]

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