Elixir: the new wave or an elegant niche?

Like a man down on his luck and coming across an old-fashioned church revival tent, I was primed to be baptized. The concise, clear language syntax. The productivity. A charismatic, foreign leader. He even drives race cars — how exotic! I came across Ruby on Rails when I was most vulnerable — fresh off a failed J2EE project in 2005 — and choosing productivity over performance was a commandant I was happy to abide by. Over the last 12 years, Ruby hasn’t let me down. . And the tradeoffs? Performance, threading, concurrency, etc? I found ways around them (or isolated myself from solving problems that needed them). I haven’t found a language that motivates me to create more than Ruby In short, I’m happily married to Ruby. Why then, do I suddenly have wandering eyes for a new language? Enter Elixir: the tradeoff-free language Last year in a conversation with an employee @ , I asked what they are most excited about in the coming years. They answered with one word: . The story was compelling. Thoughbot Elixir Elixir is a language that seems to lack tradeoffs. Its Ruby-inspired syntax is easy on the eyes. It can do things with concurrency — to a Ruby dev like me— that . All this new-age pretty code syntax and concurrency is built on top of the Erlang VM, which delivers “nine nines” availability ( ) for telecom providers like Ericsson, T-Mobile, and Nortel. mind boggling things open up a different approach to building web apps that’s 32 ms of downtime in 1 year Arguing against Elixir? It’s really hard. It’d be like losing a courtship and bearing your soul to the girl like this: ME: What do you see in that guy? Yes, he looks like a JCrew model, can sing like John Legend, and is fun to hang with. But, come on — guys like that don’t have a future beyond high school. GIRL: You know he’s going to Harvard, right? The lack of tradeoffs with Elixir makes me uncomfortable. Humans are used to making tradeoffs. Ruby on Rails represented a clear tradeoff. What’s the Elixir tradeoff, beyond its youth? Am I missing the Elixir bus at the station? I’m set in my ways as a developer. For better or worse, I haven’t flip-flopped between different languages, keyboard layouts, operating systems, and code editors. But, Elixir has my attention. I’ve started building apps with it. I’m enjoying it. My wandering eyes are turning into action. For the first time in a decade, I’m wondering: is a bus heading quickly out of the station that I don’t want to miss? There are many comparisons with Ruby and Ruby on Rails because: To answer this question, I’ve put a point/counterpoint ( like the Onion , but not as funny) below. I started with Rails prior to 1.0 and I see a lot of similarities in momentum. Ruby took off because of Rails, and Phoenix is a Rails-like framework on Elixir. Rails was a game-changer that evolved before my eyes. Finally, to clarify: this a discussion on whether Elixir is better than Ruby. I’m debating whether Elixir represents a new wave of web app development similar to what Ruby on Rails triggered. A new wave is a significantly larger challenge. is not Yes, Elixir ushers in a new wave of web apps. Elixir makes hard problems approachable to small teams. Ruby on Rails empowered small teams that focused on the user experience. These small teams could build beautiful apps in record time (think early incarnations of Basecamp, AirBnB, Dribbble, GoodReads, and ZenDesk). CRUD In 2017, 90% of my time is spent the fantastic CRUD pieces Rails provides. Elixir and Phoenix (the dominant Elixir web framework) solve today’s hard problems in elegant fashion: outside Do work across more services, in less time, in every request A single web request may gather data from several sources: a relational database, an external API, an internal micro service, a NoSQL database. Rendering the output quickly is not just based on the raw speed of the language (while Elixir is way faster than Ruby, Go and Java have Elixir beat), but how developers can perform work concurrently. easily Doing concurrency in Erlang or Elixir versus other languages is a bit like doing branches in Git vs Subversion. In Subversion it was very complicated to do — and I never did it. In Git it is a lot easier and I do it all the time. From Elixir — The next big language for the web For example, lets say I want to: Fetch a list of open issues from the GitHub API. Fetch a list of Git repo committers I’ve stored internally in a database. These calls can be executed independently of each other. Why wait for one to complete before doing the other? github_issues_task = Task.async(fn -> fetch_issues(repo) end)users_task = Task.async(fn -> users_in_db(repo) end) github_issues = Task.await(github_issues_task)users = Task.await(users_task) . There are certainly other languages that offer concurrency, but Elixir Elixir is asynchronous and non-blocking to its core makes concurrency easy. 2. Snappy, realtime, bi-directional updates with every user Elixir and Phoenix can scale to support on a single (beefy) server. ActionCable, which added websocket support to Rails 5, . With Elixir/Phoenix, most apps could reasonably provide a websocket connection to user. This makes building quick-responding, single-page app experiences approachable to every app, regardless of size. millions of websocket connections just isn’t in the same league every 3. Fewer moving parts When we write Rails applications, our Rails app depends on a lot of other pieces. Nathan Long in Why Elixir and Phoenix? A production Rails app requires several dependencies: An app server like Puma or Unicorn. A Rails app cannot spin up multiple requests. A background job framework like Sidekiq since long-running work in a web request will block. This also adds another dependency, Redis, to store job information. Another service (Monit, God) to monitor that processes are restarted when they fail. Cron for running scheduled tasks. Implementing these pieces frequently requires input from both developer and DevOps teams — there’s more coordination and friction. Elixir — where processes are as lightweight to use as objects in Ruby — allows you to perform all of the above without adding additional services to setup and monitor. Putting it all together… Web apps that can do more work per-request, communicate back-and-forth with every user efficiently, and have fewer separate systems to worry about are the next wave of apps. Elixir is approachable Keystroke-to-keystroke, Elixir is incredibly similar to Ruby. Here’s me filtering an in Ruby: Array [1,6,10].select { |number| number > 5}=> [6,10] …and the same over a in Elixir: List Enum.filter([1,6,10], fn(number) -> number > 5 end)=> [6,10] Looks the same, doesn’t it? Sure, Elixir is a functional language and Ruby is not, but line-by-line, it’s as approachable as Ruby. Like Ruby, Elixir will pull developers from multiple languages Elixir needs to pull developers outside of Ruby (its current base) to become more than a niche. It will. Smart companies like Pinterest are . in one of its selling points — websockets — and has a . migrating from Java with great success Elixir easily outperforms NodeJS far more sophisticated concurrency model In short, many of the arguments against Elixir come down to: It’s too hard convincing your boss to let you build apps in Elixir The community is too small The number of libraries available is too small Sound familar? Those are the same arguments against every language and framework — Rails included — when they started. No. Elixir is just a niche language. To go beyond a niche, you need to be . That is hard today: from Closure to Elm to Rust to Go, there’s too many specialized options for a new language to emerge as a standard. 10x better Yes, CRUD is done, but you can get close to what Elixir provides with existing languages and frameworks. Why learn a new language and framework when you can just assemble pieces for concurrency and real-time communication when you need it? Embrace the flexibility we have today for combining services — there’s no need for a monolith: Very few web endpoints concurrency. For those high-volume, critical ones that do, Elixir makes an excellent choice. But, you don’t need to migrate your entire app for a couple exceptional endpoints. require Need real-time websockets? Use a service like or . Pusher Ably It’s OK to have dependencies. Puma, Sidekiq, Redis: these are widely-used, well-maintained, and finely-tuned services. Existing languages will fix their weaknesses As Rails gained popularity, other languages quickly developed their own Rails-flavored frameworks. Same with scripting languages on top of the JVM. Ruby too knows it has a problem and is . working to fix it Inertia may be rewarded: stand pat, watch Elixir grow, and then watch your favorite language pick off the best parts. Elixir’s selling points aren’t communicated to non-developers Rails had a clear “ ” argument with productivity: it was 10x faster to build apps with it than frameworks like J2EE. 10x better Productivity is important to , not just developers. This meant the push for Rails would come from not just developers, but from managers, executives, and clients as well. everyone Elixir and Phoenix’s selling points aren’t as clear to the non-developer crowd. To be a new wave, it needs to be easy to sell Elixir from multiple sides, not just developer evangelists. Just tell me already! Sadly for those of you that read this far, I can’t tell you if Elixir represents a new wave. I’ve just added one more decision to your life. I’m sorry about that. However, . Elixir has a huge advantage if developers come up with a way to leverage these across every app in a mind-blowing way. I’d keep a close eye on web sockets Finally, , my co-workers and I are about to begin an Elixir experiment. . at my day job I’ll share the good and bad on that journey right here on Medium, so simply follow me for the story