josefrichter
Hi guys,
I came across this table from Sasa Juric’s book summarizing which common components of a (ruby) web app can be replaced with Erlang
Chris McCord mentioned in his ElixirConf 2017 Closing Keynote that it’s rather difficult for experienced Elixir devs to see the Elixir world through the eyes of newcomers again, so here we go 
For a newcomer (from Ruby world) like me, it would be quite helpful to get a bit more detail about which specific parts of the Elixir ecosystem replace those components. There’s a lot of new terms like GenServer, Supervisors, ETS, Mnesia, etc. etc. that don’t ring any bell for a newcomer, so such a mental map could fix that.
To be more specific, these are some of the questions I’m trying to find answers for:
– what do I use instead of Redis and why?
– what do I use instead of Sidekiq and why?
– how does Erlang ecosystem render some components, that are common in Ruby world, unneeded?
– how does the whole ‘concurrency’ promise help me deal with the fact that at some point all the concurrent connections might need to write into a database at once?
– what are some BAD use cases for Erlang/Elixir, where I’m better off sticking with Ruby?
– etc.
Thank you very much!
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
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.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First Post!- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
wmnnd
Hey there and welcome!
Saša’s list is, of course, a little tongue-in-cheek but ultimately true.
Let’s look at some of the points from the list:
Regarding the advantages of concurrency when you eventually still end up writing to a database: Well, not every HTTP request needs to write something to a database and even then, you profit from increased stability, responsiveness and availability of your sever if it is able to handle concurrency better
I can’t really think of use-cases in which you’d want to go with Ruby over Elixir/Erlang. There are, however, cases in which you might want to go with a language that compiles to native code (like C/C++/Rust) instead in order to get some performance benefits.
There are some nice introduction books and courses for Elixir out there. I have personally read »Programming Elixir« and it covers many important aspects of both the language and Erlang/OTP.
I can also recommend this little video series about GenServer and Supervisors on YouTube if you want to get a quick fix:
Most Liked
sasajuric
Yes, my position is that for simpler projects Elixir will help simplifying the tech-stack. So while I see occasional complaints that Elixir is an overkill for smaller projects, I personally think that with Elixir we’ll produce simpler solutions for simple problems, and at the same time we’re certain it can take us very far if things become more complex.
orestis
This 1000 times. I’m working on very small scale projects that run on a single machine. Not having to install a ton of packages for common functionality is a huge boon. In fact I’m thinking of collecting all this philosophy into a talk for some next ElixirConf… my working title is “Scaling down with Elixir”.
sasajuric
I think others have answered your specific questions, but I’d just like to address a more general point, since this table tends to be misinterpreted in a couple of ways.
It’s worth mentioning that this table is a true story, not a contrived example. I was working on these things side-by-side, and Server B was implemented in plain Erlang, as a single project. Moreover, having been involved in server A from the very start, there was no doubt in my mind that we could have moved most (if not all) of it to Erlang. In fact, since we had a lot of problems in production with server A (unlike server B which had almost no problems), I proposed we move it gradually to Erlang, and argued that this move will solve many of our problems. Reflecting back, I still feel the same.
I however caution against a general conclusion that Erlang can always replace 3rd party products. In more complex cases, an external component will likely be a better choice than a built-in Erlang option. That said, Erlang tools (such as processes or ETS tables) can definitely handle many different scenarios, so my feeling is that compared to other languages (especially scripting languages with no proper concurrency story), an Erlang (or Elixir) based project will in general require less 3rd party products and external OS processes.
Last Post!
josefrichter
…ideally up to the point where people would look at a problem and think “Rails would be overkill for this”
^ I like where this thread is going
Elixir Recipes could be some sort of community-driven Wiki maybe.. Or at least a blog post.
Thank you everybody!