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.
|Elixir/OTP fixes distributed computing||No. Distributed computing is unavoidably hard.|
|Elixir makes distributed state easy||No. It’s still hard and most people should build stateless apps.|
|Distributed Elixir solves microservices||No. Most still use HTTP/JSON, and this is reasonable.|
|Elixir apps scale without rewrites||No. You will always need to change at scale.|
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.
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.