I read about process dictionaries and how they introduce side effects but how are states different from process dictionaries ? Shouldn’t process states introduce the same issues that process dictionaries have ?
The process state is explicitly maintained by whatever code runs in a process. The process dictionary can be written to and later retrieved without the code running in the process passing it on.
Process state is the value passed to you in the function argument, process dictionary is black magic that you probably should never touch on your own unlike you will really know what the hell is happening.
1 Like
Don’t say “never”, it’s more like you should wait until you’re a senior dev that has seen how it’s used under the hood in elixir and understand fully why that choice is made where it is 
and understand why your code is not that.
1 Like
In my post s/unlike/until and it will make more sense. Unfortunately I cannot edit myself now 
1 Like
But Agent actually allows us to use the state as a mutable variable right ? It can also be written and retrieved later.
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.
10 Likes
Thanks a lot for the answers everyone.
