For you? Sure, it seems it was the case. 
For everyone, I highly doubt.
We are talking about misuses of Agents. So yes, they should not be using agents nor the process dictionary. I was wondering which one is less problematic.
josevalim
Creator of Elixir
net
I have never used an Agent either.
To me, “Agent” is a bit of a misnomer. “Agent” coveys to me a sense of doing, rather than holding.
1
sasajuric
Author of Elixir In Action
Call/cast dilemma also needs to be understood with agents (because there’s cast function).
Thanks to Elixir, some GenServer aspects can be ignored initially (I bet you wished there was Elixir when you started learning Erlang 
). With use GenServer basic usage requires start_link, call, and cast (and respective callbacks). In fact, a simple explanation could just stick with a call, and that’s already in many ways on-par with agents.
If we’re talking about misuses, I think that procdict is a lesser evil here because:
- It gives better runtime properties (no copying, scheduler overhead, potentially leaking processes)
- procdict should be a stronger hint that you’re probably doing something wrong
2
josevalim
Creator of Elixir
mjadczak
Just on this topic, are there any guidelines on when using the procdict is actually appropriate?
1
OvermindDL1
In my opinion, only for hidden ubiquitious state, like the random module uses it, and gettext uses it, it saves the callers from passing around and holding state into those, but that absolutely should be minimized as holding on to and passing state is superior in almost all cases except those trivial ones due to their ubiquity and ease of use.
1
sasajuric
Author of Elixir In Action
I agree with everything @OvermindDL1 said, but I’d like to expand on his comment about passing state vs procidct (or agent).
It has been hinted in this thread that agents might be helpful when it’s tedious to thread some piece of info (accumulator) through a deeper chain of nested functions. As I said, I do think that procdict is not as bad as agents for this, but a much better solution is IMO usually to pass the data around.
For example, let’s say you have a bunch of functions which maintain foo and bar, meaning they accept foo and bar, and return a tuple of {foo, bar}. Now, you want to add baz, and it feels like a huge amount of tedious work to add this piece of data, so it might be tempting to use agent or procdict.
The proper course of actions would be to bundle these fields into a map, and then you have functions which take a map, and return a transformed version of it. Adding additional pieces of data to this map is then simple. Such map with associated functions then captures some concept explicitly. If the logic around this data grows (you find you need more fields and/or functions working on the map), it’s likely the time to extract that code into a separate module (and maybe turn a map into a struct).
There are cases when passing the accumulator is extremely tedious, for example if most of the functions in the stack don’t care about the accumulator at all. A good example of that is RNG. If :random didn’t support procdict, you’d have to explicitly pass the RNG state through all the functions, just because you need a random number somewhere deep in the stack.
But in most cases, using procdict to accumulate something is a q&d shortcut, rather than a proper solution. Using agent for this is even worse, for technical reasons I mentioned
1
Qqwy
TypeCheck Core Team
I guess the main reason why using procdicts is considered a dirty hack in most cases, is because it breaks the Referential Transparency that functional programming enjoys. If code is not referentially transparent, it is hard to maintain, because there may be hidden dependencies that you overlook while refactoring, resulting in bugs that are hard to track down.
5
smpallen99
Interesting discussion… Hard to believe someone would use an Agent for in-process state management. I don’t think that’s the fault of the tool, but of the person’s experience with functional programming.
Personally, I use Agents, ETSs, GenServers and FSMs a lot in my solutions. I’m not that fond of ETS so I normally default to an Agent. However, ETS has some nice query functionality that I reach for if needed.
For simple long running state, Agents are nice. Less setup then GenServers. Agents are also handy for simple serialized “read and do something with the value” operations.
When I need state and more complex behaviour, I use a GenServer. Both approaches are faster than database access IMHO. Of course, I only use these for transient data and resort to the database when survivability is required.
I personally feel the addition of Agents to the language was a good thing. When they first came out, I didn’t really understand why I wouldn’t just use a GenServer. However, after learning them and a couple uses, I would miss them.
1
robconery1
Well… guilty as charged. I feel as though I have a pretty good understanding of the language and how functional programming works in general, but just yesterday I was coding up some ShoppingCart code and thought “hmmm, should I use Redis or should I use an Agent”. ETS occurred to me as well, but I’m not really sharing any data between processes… yet. So I went with what I considered to be the more idiomatic, “simpler” solution: Agent.
I mean… I dunno it kind of fits the docs:
Often in Elixir there is a need to share or store state that must be accessed from different processes or by the same process at different points in time.
So: the docs suggest this is a reasonable approach, my intuition suggests the same. Does this mean I don’t understand functional programming? Nope. Let me explain why…
I ended up on this thread because something didn’t feel right about this decision. I didn’t know how to kill it aside from using a cron job - I need these carts to expire. So naturally I’m thinking Redis or Mnesia - but carts are kind of transient. I’m not interested in the Cart itself, and I’m only interested short-term in the “state” of the cart. A cart will either be used to execute an order in the near-term, or it won’t.
This is where the functional break happened in my mind: I’m much more interested in the data produced than the cart’s behavior. Logs can tell me much more than the current state of the cart and an arbitrary status flag.
Anyway: I start to wonder how I can use Elixir to terminate a cart after a set amount of time. I’m thinking about a watchdog process and a bunch of other “let’s see what sticks to the wall” kind of stuff and I come back to the same realization: Redis does this better. So I Google it and end up here and damn I’m happy I did because I was asking the very same questions: what are Agents good for anyway?.
I ended up here, read this great discussion and am very happy to know I’m not the only one having these thoughts. I’m also glad I’m not alone in appreciating :mnesia.
Thanks again - great discussion.
3