hubertlepicki
I have been thinking about GenEvent today when reading the fantastic book “Designing for scalability with Erlang/OTP”. I do not really like it (gen_event, I love the book), in fact, I can hardly justify using it in any but the simplest cases where nothing can go wrong. It is difficult to set up correctly and adjust to different use cases, I think mainly because it runs the handlers in process of manager. But since here are so many great more experienced Elixir and Erlang devs than me, I may as well reach out to get your opinions on the topic. Two questions from myself:
-
Is GenEvent really that bad as I think it is, or do you actually use it and can recommend doing so?
-
What GenEvent alternatives would you recommend?
You already got my opinion on 1, just a quick note on how I have been dealing with events handling now: I use third party gproc lib and implemented my own solution based on it’s pub/sub use case. My event handlers are started as stand alone processes (GenServers with handle_info callbacks in fact) and supervised/restarted entirely separately than my event manager.
I think @josevalim is working on gen_broker (a.k.a. gen_router), and it may be interesting alternative in the future, but I do not think it’s ready just yet.
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
sasajuric
For the reasons you mention I’m not a fan of GenEvent myself. I also prefer gproc with property based registration and discovery. With this approach error recovery is easy to do using supervisors, while the discovery of subscribers is left to the registry.
Based on the ElixirConfEU keynote by @josevalim, it looks like gen_broker will support something similar, but with the additional ability to apply back-pressure. It’s hard for me to comment on this until it lands. So for now, my go-to approach for notifying an unknown number of subscribers is gproc.
I should mention that I consider gproc only as a local registry, and don’t use it as a global one. For issuing notifications in the cluster I’d recommend Phoenix PubSub. In the next version it will be a separate library, so you don’t even need to depend on the entire Phoenix to use it. Another alternative is pg2. It doesn’t have all the goodies of the next PubSub (most notably presence), but on the upside, it’s available out of the box, so no need to add another dependency.
hubertlepicki
@sasajuric thanks for the tip about Phoenix PubSub. It looks on a first sight that the work is really advanced / close to being completed on extracting it. So it may be very much usable already: GitHub - phoenixframework/phoenix_pubsub: Distributed PubSub and Presence platform for the Phoenix Framework · GitHub
eksperimental
Jumping in just to mention that once GenBroker makes it to Elixir (probably v1.3), GenEvent will be deprecated from Elixir
so you know where you energy goes to if you are planning on learning GenEvent
hubertlepicki
I am just watching the keynote Jose gave on this Elixir Conf EU, and it is very much relevant and describes the plans ref GenEvent alternative.
hubertlepicki
And the second published talk, by @chrismccord is also very much relevant. Looks like phoenix_pubsub is going to be perfect replacement for GenEvent (and more) for classic pub/sub use cases and process groups etc.
hubertlepicki
I will probably wrap it up in a blog post. But I have tried pg2, gproc, also stand-alone phoenix_pubsub. Then I found this gem:
https://github.com/ostinelli/syn
it has some nice features, like sending message and collecting responses (multi_call), pub/sub and presence out of the box. Does seem to work great in clustered env, while I had real trouble getting gproc to work.
Gproc seems to depend on gen_leader which is not like one library but dozen of forks, forks of forks, and people would not agree which one is least buggy. This seems like a real mess, which is an indication to me to avoid the project at all.
ijunaidfarooq
Did you try to replace GenEvent with Phoenix PubSub? and how it went?