Introduction

In Erlang, processes do not return multiple values to one another the way a normal function call might. They send one message at a time, and that message can contain as much structured data as you need. The usual way to send "multiple values" is to package them in a tuple, map, or list and then pattern match on the receiving side.

Send One Message That Contains Multiple Fields

The send operator is simple:

Pid ! Message.

If you need to send several related values together, wrap them in a tuple.

ReceiverPid ! {user_created, 42, "alice", true}.

The receiver can unpack them with pattern matching.

1receive
2    {user_created, Id, Name, Active} ->
3        io:format("Id=~p Name=~p Active=~p~n", [Id, Name, Active])
4end.

That is the normal Erlang way to pass multiple pieces of information between processes.

Tag Messages So Pattern Matching Stays Safe

Notice the atom user_created in the first tuple element. That tag matters a lot. It distinguishes this message shape from other tuple-shaped messages in the mailbox.

Without a tag, unrelated tuples can be harder to tell apart.

A good message often looks like:

{event_name, Field1, Field2, Field3}

rather than just raw positional values.

Maps Work Well For Named Data

If the data has many fields or may evolve over time, a map can be clearer.

ReceiverPid ! #{type => user_created, id => 42, name => "alice", active => true}.

Then receive and match on the keys you care about.

1receive
2    #{type := user_created, id := Id, name := Name} ->
3        io:format("~p ~p~n", [Id, Name])
4end.

Maps trade a bit of compactness for readability and extensibility.

Request And Reply Pattern

A very common pattern is sending a request that includes the sender pid, then waiting for a reply.

1server_loop() ->
2    receive
3        {get_sum, From, A, B} ->
4            From ! {sum_result, A + B},
5            server_loop()
6    end.

Client side:

1ServerPid ! {get_sum, self(), 3, 4},
2receive
3    {sum_result, Result} ->
4        io:format("Sum=~p~n", [Result])
5end.

This is often what people really want when they ask about sending and receiving multiple values.

Mailboxes Contain Mixed Messages

A process mailbox may hold many message types. That is why pattern matching matters. The receive block scans for the first message that matches one of its clauses.

1receive
2    {ok, Value1, Value2} ->
3        {Value1, Value2};
4    {error, Reason} ->
5        {error, Reason}
6end.

By choosing a good message shape, you make concurrent code much easier to reason about.

Use Lists Only When The Data Is Naturally Repeated

Lists are fine for variable-length sequences, but they are not always the best choice for a fixed set of fields.

ReceiverPid ! {batch, [1, 2, 3, 4]}.

For a fixed number of values with specific roles, tuples are usually clearer.

Common Pitfalls

The biggest mistake is thinking Erlang can somehow "send several separate return values" without packaging them in one message structure. Another is omitting a message tag and then making mailbox matching ambiguous. Developers also often forget to include self() in request messages when they expect a reply from another process. Finally, a receive block only handles matching messages; unmatched messages stay in the mailbox, which can surprise people during debugging.

Summary

• Erlang sends one message at a time, but that message can contain multiple values.
• Tuples are the usual way to package a fixed set of fields.
• Maps are useful when named fields make the protocol clearer.
• Include a tag atom in the message so receive clauses stay precise.
• For request-reply patterns, send self() so the receiver knows where to answer.