I’m actually quite curious as to how it is used. A GenServer passes a single state argument to all callbacks, which seems no different from a pid for an agent, you can pass both sets to functions to mutate the data within and return it, it just seems like a lot of overhead and extra code so I am curious as to the benefit?
OvermindDL1
accuser
I think the main benefit is to me… 
Specifically, I start my GenServer with a unique id, which in turn starts the Agent with an initial state, perhaps a record loaded via Ecto. The Agent contains a number of functions that transform its state via get_and_update/3, returning the changes and the new state. The GenServer manages the logic that invokes those transformation. It checks that the command is valid, etc.
I’ve adopted this approach for a couple of reasons:
-
The Agent is only concerned with what is needed to be done to transform the state of the struct it wraps. It could be a record from Ecto, but could also be a remote service. Nothing needs to know how it works, only that it does.
-
The GenServer is only concerned with how the Agent should be transformed.
-
A complex command might chain several Agent transformations together, and this reduces code duplication.
2
OvermindDL1
Hmm, I’d probably have stuffed that record into the state (or ‘as’ the state if nothing else).
Wait, how do you do this? Adding functions to an Agent basically just means a GenServer, so why not just have it all in a GenServer?
Yeah, that should be a GenServer, you only add things to that GenServer that relate to messing with its own state.
That could also be another GenServer, but you would not need to keep the transformation for the agent in ‘this’ genserver but could keep it with the data itself in the other genserver directly.
Hmm, how does this work? Code examples?
1
accuser
I started with a GenServer having the entity as part of the state, but it soon got complex. I don’t mind writing more code in order to reduce complexity. I then migrated the entity to an Agent, and added some helpers. See this gist - caveat, I have macros for handling parts of this, and have extracted this simple case as best as I can. Mea cupla if it doesn’t serve the purpose! 
1
OvermindDL1
Just because the GenServer holds the state does not mean all the functionality needs to be within it. Like on your User.Entity.activate/1 function, why can it not just take the user instead of the pid, then get rid of lines 13 and 17 then the part at User.handle_call/3 on line 18 can just store it back as the new state, then it becomes fully functional, code flow is well defined, no weird magical calls that return nothing are sitting around, and so forth… I’m not sure what an Agent here is for other than maybe obfuscating what is happening. It does not seem to be very functional at all as well as being quite a bit slower than just a direct method call to the other module would be since it has to pass a message, copy data, set new data in the other process, then send a message back, etc…?
1
accuser
I’m glad you said that, because I have been thinking about that recently. I’ve been coding Ruby (on and off Rails) for the past 10 years, and have brought some of that baggage with me, no doubt. I started my current project with a prototype using DRb, and so naturally gravitated to Elixir when I came across it (I’m actually from a Telecoms background, and was well are of Erlang/OTP, but never got around to using it).
So, back to the issue in hand - you’re saying that my I should drop the Agent, stick with just a GenServer, but keep the transformation functionality in a separate Module, passing user as a parameter. I can see the sense in this.
3
OvermindDL1
Yes absolutely! That is how my GenServer’s often are. The code that operates over the data and returns new data is elsewhere, the GenServer itself just handles the synchronization and messages to call the right commands and hold the state.
EDIT: Just keep this in mind, the fundamental unit of Code Organization is not a Process on the BEAM, it is a Module. You should always jump to a new Module first and pass data around instead of a process until you really need a process, like for concurrency or so.
9
sasajuric
Author of Elixir In Action
1000x this!
I’ve seen multiple cases where people reach for Agents to organize their code, where plain functional module would do the job. I even remember seeing somewhere someone stating that such approach is functional (because presumably Elixir is functional), which is definitely wrong.
My feeling is that since Agents are easy to use, they are also easy to abuse. Moreover, I believe that Agents solve a fairly trivial problem, and are basically just reducing LOC compared to GenServer. Which is why I only use Agents in tests (where they really come in handy), and avoid them otherwise. YMMV of course
6
gregvaughn
With all respect to José, even when they were first introduced I found Agents to be uninteresting. I learned GenServer first and that’s still what I tend toward. I even took a detour into Clojure at a prior job, and I learned agents there, but GenServer is so much more.
3
josevalim
Creator of Elixir
I will take that as a compliment. 
I also don’t tend to use agents much but, in the few cases I do, I prefer them to a GenServer. A GenServer, as the name says, is generic so when you only need to keep state around, the intent gets lost. Other than that, a GenServer is likely the way to go and is definitely much more.
Answering the original question: Mix has two or three examples of using agents.
2