Explicit sends and receives
Activities can cooperate through shared memory or by sending information to one another. Message passing makes that exchange explicit: one task can send a computation request and another return a result. Their local execution can be described separately, with communication rules specifying how those activities are brought into coordination.
Synchronous and buffered channels
A channel can constrain the type of transmitted data and combine communication with synchronization. In Go, an unbuffered exchange requires a matching sender and receiver, while a buffered channel can hold values up to its capacity. Buffering changes when operations must wait, not merely how much storage a channel occupies.
References: [2]
Mailbox-based communication
Erlang addresses processes through process identifiers and lets receivers select suitable messages from a queue. This mailbox model differs from a rendezvous requiring both sides to be ready together. Unmatched messages still need consideration, and sending a message does not itself demonstrate that the requested operation has completed.
References: [1]
Designing the conversation
Useful conversations require agreed message formats, request identifiers, replies, and completion signals. A receiver may exit or a request may time out; retries can duplicate an operation. Explicit messages make these interactions visible, but application-level ordering, acknowledgments, and exactly-once behavior still require a deliberately designed protocol.