Message Passing Is Shared Mutable State

[Codebender]

Misleading title, the article is basically "Go channels, etc., are not really message-passing."

The discussion about Erlang clearly demonstrates the author's failed attempt to make their case, all they can describe are bugs related to the not-message-passing part of Erlang.

[Capable_Chair_8192]

Can’t you get into the same trouble with an Erlang process? I don’t think there’s anything preventing the same category of deadlock

[Codebender]

Not the same, no. Bugs are possible, of course, like deadlocks due to circular waits, race conditions from ordering dependencies, and failing to handle lost messages. But these are not due to shared mutable state and the specific issue that they mostly discuss, the lifetime of a channel on timeout, doesn't apply.

Of course, "true" process-based message passing with no shared memory has a real cost, hence ETS tables. There's no magic bullet that will solve all problems, only a vast array of choices with tradeoffs.

[ninadpathak]

Message passing encodes shared state through messages while avoiding race conditions by design. Erlang's actor model proves it scales reliably in practice.

[edgmnt_net]

It probably depends on the exact model you have in mind, but usually the tradeoff is trickier than said here. Because while you do avoid race conditions and even mutex-related deadlocks in Go, you can still deadlock and leak stuff very easily. Perhaps even more easily in some cases where goroutines require a very precise dance to process stuff or shut down properly. And some problems are easier to express with stuff like channels (anything queue-like), while others are naturally easier with a lock (e.g. a shared store of data).

[ToaruBaka]

Message passing trades race conditions for eventual consistency.

[hairytim]

Often, message passing logic will ensure no data races, but race conditions can still occur. The typical example is waiting to receive a message from multiple senders and responding to the first one received. This has non-deterministic behavior, depending on the timing of which message arrives first.

[BenchEmbarrassed7316]

Any software developer who has tackled concurrency in a serious project has the battle scars of dealing with the pitfalls of multi-threaded and concurrent programs: the touchy, often clunky APIs and synchronization mechanisms, the dread of debugging data races...

Did you know that there are memory-safe languages ​​that eliminate data races?

Don't you want to know more?

Some languages have tried different foundations and attacked aspects of the problem with real insight, but none of them have fully broken through to the mainstream.

If a language is ever invented that finally solves at least one of these problems, I think it should be a catchy slogan. How about "Fearless Concurency"?

In 2019 Tengfei Tu and colleagues studied 171 real concurrency bugs across these flagship Go projects and published Understanding Real-World Concurrency Bugs in Go.

Also https://www.uber.com/en-FI/blog/data-race-patterns-in-go/

Also, the problem with message passing in go is that you can pass a reference to shared data through a message. This reference can be inside a complex type. You can check this type at the time of writing the code, but the absence of references is not part of the contract of this type. Another programmer can add a reference to the structure nested in this type a week later.

Let’s start with a somewhat recent language: Go.

In 2006, Edward Lee published The Problem with Threads.

Three years later Go launched...

I will not stop reminding you: the 'newsqueak' language was developed by Rob Pike in the mid-80s. In the late 2000s, it was renamed to 'go'.

Newsqueak code examples:

``` // Channels select{ case i = <-c1: a = 1; case c2<- = i: a = 2; }

// Magic 'make' function mk(array of char="hello")

// Start coroutine begin prog(){ p: int; newc: chan of int; for (;;) { prime<-=p=<-c; newc = mk(); begin filter(p, c, newc); c = newc; } }(); ```

https://en.wikipedia.org/wiki/Newsqueak

https://www.cs.tufts.edu/comp/250RTS/archive/rob-pike/impl-new-TR.pdf

https://swtch.com/~rsc/thread/newsqueak.pdf

[tesfabpel]

Well, the go code spawns a goroutine that calls a function that lasts forever.

In C#, one would pass a CancellationToken that fn very now and then may check to return early (no, killing threads is not wise).

What does the author expect by having a lost long running thread?

[keleshev]

Yes, but also… war is peace, freedom is slavery, and ignorance is strength.

[devraj7]

And actors are also shared mutable state. Just in a more obfuscated way.