We also use it in Gettext to store translations being extracted during compilation.
whatyouhide
Elixir Core Team
mjadczak
I use it as a simple KV store when parsing things into DAGs, which is notoriously difficult to do in a pure functional style (especially without more hardcore tools like Monads et al.)
I think in general it seems that most of the “good” use cases are short-lived accumulator-like processes, for times when insisting on passing accumulators around in a pure functional style gets too complex. For long-lived computation or processing or state storage, I definitely reach for a GenServer.
0
OvermindDL1
A monad is not hardcore, heck if you pass state from function to function (like what |> does already) that is just explicit monad handling instead of implicit, the monad in this case is just a raw value. ^.^
For anything in-process I still think passing the state around is better, after all you have to pass the PID around anyway. ^.^
For out of process I usually hit ETS, why spin up an agent when ETS can do it better and faster?
For out of node, well a GenServer, but an agent might have use here, or Mnesia depending…
0
sasajuric
Author of Elixir In Action
I don’t think these are good use cases. If you really want that (and I believe in most cases it’s not a good idea), then consider process dictionary. At least with that, you won’t need to pay the price for the separate process, copy data, and depend on the scheduler. An example of that in practice is :rand.uniform which uses procdict to implicitly manage the state of the RNG.
2
mjadczak
I have actually looked at :digraph, what I’m doing isn’t exactly processing arbitrary DAGs and the module isn’t a good fit—but yes, I suppose I’m using an Agent as a lightweight alternative to an ETS table (all it does it keep two maps around) as the structures I’m working with are quite small (couple hundred entries at most).
0
mjadczak
Here is another of my uses of Agent: I’m using it as a lightweight cache to the database while doing an import of a dataset. There are a bunch of references to things and also some things which I am denormalising, and keeping things in memory instead of going to the database speeds things up when importing thousands of records.
defmodule PFServer.Finder.ImportMeta do
@moduledoc """
Keeps track of information during an import, and asynchronously imports program types and focus areas.
"""
alias PFServer.Finder.{Organization, ProgramFocusArea, ProgramType}
alias PFServer.Repo
alias PFServer.TransactionManager, as: TM
require Logger
defstruct importing?: false, organization_map: %{}, ptypes: %{}, fareas: %{}
def start_link do
Agent.start_link(fn -> %__MODULE__{} end, name: __MODULE__)
end
def start_import do
Agent.get_and_update(__MODULE__, fn state ->
cond do
state.importing? ->
{{:error, :already_importing}, state}
true ->
{:ok, put_in(state.importing?, true)}
end
end)
end
def end_import do
Agent.update(__MODULE__, fn _ -> %__MODULE__{} end)
end
def register_organization(%Organization{id: db_id, airtable_recid: recid}) do
Agent.update(__MODULE__, fn state -> put_in(state.organization_map[recid], db_id) end)
end
def get_organization_id!(recid) do
case Agent.get(__MODULE__, fn state -> state.organization_map[recid] end) do
nil -> raise "Organization with record ID #{recid} has not been registered."
id -> id
end
end
def get_program_type(name) do
Agent.get_and_update(__MODULE__, fn state ->
case state.ptypes[name] do
nil ->
ptype = TM.execute fn -> Repo.insert!(%ProgramType{name: name}) end
{ptype, put_in(state.ptypes[name], ptype)}
ptype -> {ptype, state}
end
end)
end
def get_focus_area(name) do
Agent.get_and_update(__MODULE__, fn state ->
case state.fareas[name] do
nil ->
farea = TM.execute fn -> Repo.insert!(%ProgramFocusArea{name: name}) end
{farea, put_in(state.fareas[name], farea)}
farea -> {farea, state}
end
end)
end
end
However even looking at it now, a case could be made that it should actually be a GenServer, given that it’s doing a little more than just keeping state. But then, all Agent is is a wrapper for a GenServer with a different API.
Looking at it more, even though usually we have all the logic to manipulate an Agent’s state inside a single module, an Agent is more like a “promiscuous” GenServer, in that in a typical GenServer setup, the logic to manipulate GenServer state is inside the GenServer itself and we have a functional interface to the GenServer. An Agent, on the other hand, allows us to provide it with arbitrary lambdas to modify its state.
This breaks a lot of conventions in OTP/Elixir in general, and I think that’s why there’s such an instinctive dislike of them in this thread.
It begs the question—should they even be included in Elixir by default at all?
1
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Just judging by your Agent code here it seems like you could just as easily have a cache that was just a map and do it all in a purely functional style.
I don’t understand what this means. They aren’t arbitrary, they take the state and they return very specific values. This is exactly like a GenServer which has particular callbacks that take the state, arbitrary arguments, and return specific values.
1
sasajuric
Author of Elixir In Action
The issue you mention is indeed one drawback of Agent, but my main concern is about something else. I have an increasing feeling that agents are frequently misused as objects, where in-process structure would work just fine. I share Ben’s impression of your code:
Looking at the interface of your module, it looks like it serves as a dumping ground used by a sinle process. If that is indeed the case, I think that plain data structure would work better. We had other examples in this thread where people used agents to organize the code, or maintain some accumulator in a loop.
While I agree Agents offer some benefits over GenServer when properly used (as demonstrated in mix and gettext examples), I’m not sure these benefits are worth the downsides:
- Agent is the additional abstraction people need to learn.
- People (especially newcomers) seem to be confused with Agent vs GenServer. Over years, I’ve repeatedly seen people asking which one should be used.
- As you mentioned, by default agents break encapsulation.
- It seems that agents are easily misused to work around FP and simulate OO. Admittedly that’s also possible with GenServer (I know for a fact because I used to do that myself
), but it requires more overhead compared to agents. Wrapping e.g an integer in an agent is trivial. Doing the same with GenServer will require a dedicated module, so that’s a hint that perhaps this is not the best approach
Given these downsides, and the fact that I’m personally not superimpressed with supposed benefits of Agents, looking at your question
I personally feel that we’d be better off without agents.
2
mjadczak
What I mean is, the default interface of an Agent expects a lambda to be passed in at runtime to tell it what to do with its state. Most of the time that is encapsulated inside another module anyway, but it is different from a GenServer which requires you to write a new module, and perhaps specifically accept and execute lambdas if you explicitly want that behaviour for some reason.
I get your points here. The key issue here is that the processing/importing is done in parallel/concurrently over several processes. The agent here acts as the cache as well as a point of serialisation. The main issue is that I have e.g. “Focus Areas” stored as strings inside the source data, but I am normalising them into a database table. Instead of executing an atomic “insert if not exists and get me the ID” query against the DB for every single record, I serialise this through this process which keeps track of which ones have already been inserted.
There is admittedly no reason why there’s an advantage to this being an Agent instead of a GenServer though, I think. Perhaps Agents were an initial backlash against the “boilerplate” of GenServer—initially I also thought that the triplication of functions “just to do one thing” was annoying, but then I got used to it.
Maybe requiring people to understand what’s going on inside the GenServer before they use it instead of allowing the “quick win” of a simple interface which then leads to misuse would be better.
2