**** Exact wordings from the website https://uniwebsidad.com/libros/concurrent-erlang/chapter-1/concurrency:
The primitive receive takes the first message which matches one of the message patterns from a queue of messages waiting for the attention of the receiving process. If none of the receive patterns matches then the process is suspended until the next message is received – unmatched messages are saved for later processing.
I would say that with the messaging model chosen by Erlang, i.e. a process having a single mailbox for incoming messages from all origins, selective receive is a necessity.
Without selective receive you wouldn’t be able to do communication in nested function calls without destroying the structure of the program, or inventing conventions like having a message queue somewhere in the process’ global state or passing that queue around all over the place (similar to how state is modelled in continuation-passing style denotational semantics).
(For a very simple and common example, consider a gen_server that while processing some particular message calls into some code which performs some other communication. That could be to an external system, or some local service that happens to be a separate process. Communication while handling other communication is as normal as recursive function calls are.)
There are alternatives that can do without selective receive, like channels and the ability to communicate over any number of channels, but they bring other complexities into the system.
Thanks for the detailed response. I now understood the Selective receive. Erlang message processing is a lot different than Akka.
I am not aware of continuation-passing based concurrency. Also, I am few days into Erlang. I will read your response later to understand all the aspects explained by you.