Is the Elixir Hype Real?

As I have written previously, I had a burning question I wanted to answer while attending this year’s ElixirConf: “Is Elixir good enough to demand mainstream adoption?” Now that ElixirConf 2018 is behind us, I think the answer is definitely yes. But it’s not for the reasons I expected.

My Expectations vs. Reality

I adopted Elixir very early on in 2014, because I was bored at my day job and I saw its potential. From the beginning, I hoped that it would be a magical elixir (heh) that would make everything hard easier. As both I, the language, and the community have matured, those expectations have been tested.

Few people at the conference were using distributed Elixir. Many were running Elixir on a single node. Nobody had a silver bullet for how to distribute your computing or your state. Those who had microservices were communicating using standard protocols like gRPC or JSON over HTTP. Elixir may have tools that will help with these problems, but they aren’t mature and few people seem to be using them.

Reality is Good Enough

Yet, people appear to be very happy with Elixir and are adopting it at a rapid pace. ElixirConf was well attended, and half the attendees were new. Many Elixir jobs were advertised, and the community seems very healthy and growing.

It seems that for many people, a high performance, concurrent, simple language with familiar syntax is just what the doctor ordered. Elixir doesn’t need to fix distributed computing to be interesting, it just needs to offer a productive, fast, concurrent runtime.

Other languages may offer higher performance, or be able to hold their own in the microservice space, but none offer the unique blend of productivity and performance that Elixir offers, especially when you are developing fatter services. Despite the microservice hype, most of us are building fat services or monoliths, because that’s all our problem space requires.

In particular, most other languages lack one or more of the following important features, while Elixir has them all:

• High quality frameworks for fatter apps
• Sane package manager
• Simple, clear syntax with minimal ceremony
• Actor-based concurrency with fault tolerance
• Excellent documentation tools
• Code formatter
• Metaprogramming (when you need it)
• Development via REPL
• Active, helpful community

These things matter less when you are writing tiny microservices, but they are invaluable when working on a fat service or monolith. Since this is what many people are building, I expect that this advantage will produce slow, steady growth in the community.

One More Thing…

ElixirConf ended with a bang as Chris McCord dropped a demo of Phoenix.LiveView, an upcoming Phoenix feature. Think of it as server-rendered React components, powered by Phoenix channels.

If this works as advertised, I think it will launch Elixir and Phoenix into the mainstream. Imagine if you could have a high performance, realtime, interactive web app without writing Javascript or JSON APIs, maintaining two codebases, or two developer teams. Imagine the time and money you could save!

This will be a powerful draw for startups and anyone doing greenfield development, particularly Rails developers. They really don’t want to write Javascript. Chris describes here and in other talks why this technique can’t work in Ruby. I suspect it will be difficult to copy in many other runtimes, because you need isolated, high performance processes to do this. Elixir has a real advantage here.

Phoenix has a real opportunity to advance the state of the art by making realtime views this easy. If it succeeds, the browser refresh button will soon seem like a thing of the past, which is exactly the kind of leap that Rails gave us in 2004.

So yes, Elixir is good enough. The past few years have built Elixir’s critical mass, and with this kind of innovation pushing forward, it seems to me that Elixir’s time is almost here.