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.

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

I think then, that it’s important to emphasise that one of their main purposes is to be a teaching tool, rather than a core piece of the Elixir infrastructure that you should construct your codebase out of. I do agree that when I was starting out, considering Agents first allowed the actual messaging model to sink in before I had to worry how callbacks and behaviours worked.

I am one of the people at the stage where I feel I have a very good grasp on the “basics” of Elixir / OTP, which is what the literature seems to focus on. I have a couple of simple, non-critical apps in production. I know how processes and supervision trees and releases and applications and clusters work. However I definitely feel frustrated by the lack of literature which covers more advanced topics and how and when you should actually deploy these more advanced tools like ETS or Mnesia when dealing with “real” systems, and the gotchas and caveats that apply.

I did breeze through the introductory material—most likely because I had already been exposed to functional programming as well as traditional “formal” concurrency models like CSP—and I feel like I’ve suddenly hit a wall in terms of further learning; for now the only way forward has been to push forward, make my own mistakes and learn from them (often with the help of the wonderful community here).

I think that if we want to encourage more people without an Erlang background to actually build non-trivial, production apps which take advantage of the power of OTP, and not just treat it as an interesting and powerful language, but only for side projects, this space definitely needs to be developed some more.