Yes both maintain state. The difference is in how the state is maintained. For process state the state data is explicitly passed as parameter in the function the process runs - most often called the process loop. This is essentially tail call based recursion and therefore functional at its core.
The process dictionary however doesn’t use recursion, but side effects to store data. I’m not even sure if the dictionary is also on the process heap like normal process state. In the end it’s something quite different than process state from an implementation perspective.
I’ll try to illustrate this with some code:
spawn(fn ->
fn ->
receive do
msg -> msg
end
end
|> Stream.repeatedly()
|> Enum.reduce(initial_state, fn msg, state ->
next_state = handle_message(msg, state)
next_state
end)
end)
This is kinda how a process loop works. State is continuouesly aggregated by a reducing function handling the last state and a received message from the outside. State is maintained by passing it as parameter to the next reduction. It’s never really stored somewhere, but part of the callstack. Most of the time you never see this part in your codebase though, because it’s handled by the various :gen behaviours we’re all using. E.g. in the above case a user would just need to provide handle_message, while the rest of the code wouldn’t need to change.
The process dictionary on the other hand is a “database”. It’s a key-value table you can put kv pairs in and then it’s just there, no matter what code runs on the process. Kinda like a process specific ets table.
