Elixir Can Save Your Company Money

I’ve known it as the “Iron Triangle” but it goes by many names, such as the Project Management Triangle but the idea is all the same: In software development you have three constraints to control the outcome of a project but you can only change two of them. So you can have it:

• Fast & cheap, but not good
• Fast & good, but not cheap
• Cheap & good, but not fast

This is a generally accepted rule of thumb, with a few exceptions. And I believe that building software with Elixir is on the cusp of being one of those exceptions.

Let’s get this first part out of the way: I really like Elixir. I retooled DockYard around it back in 2015 and have been very active in the ecosystem since. So I’m biased, but not without reason. I’ve been through several technology ecosystems in my career and I can say definitively that Elixir is the first one I’ve encountered that can truly deliver on its promises.

Across all aspects of software development in Elixir we at DockYard have consistently seen:

• Less time required to build new features from scratch. This directly translates to smaller teams necessary to build similarly scoped features in other languages.
• Less ongoing maintenance of the language as it is effectively “done” at this point. Upgrade paths are no longer a concern or a reason to shut down feature development to bring your application up to the most recent releases of dependencies.
• Bugs are resolved quickly.
• New features require less time to integrate into the existing application.

All of these savings directly translate to less cost over time. But don’t take my word for it. Here is a list of case studies from well-known companies that have seen similar results

• Bleacher Report: They migrated from Rails to Phoenix and reduced app servers from 150 to just eight. They also reduced their team size as they no longer required as many developers to support their ongoing needs.

• Change.org: In 2018, they needed to migrate their messaging system from an external vendor to in-house. In the process of creating the new system–which would need to handle millions of events and keep up with near-constant communication–they built prototypes in four languages before landing on Elixir. Less than a year later they finished their migration ahead of schedule, and with a system capable of handling a 10-million-message spike in use while keeping memory usage at less than 5%.

• PepsiCo: Initially PepsiCo only planned to use an Elixir application to manage search marketing operations. Several years later, its role has grown to play a key part in how PepsiCo’s marketing and sales teams use data and integrate with search marketing partners. One software manager specifically linked Elixir’s ability to offer a robust developer experience to improved consumer experience.

So why isn’t everyone using Elixir? Let’s discuss the two biggest reasons that I have seen and how DockYard is helping address them.

1. Talent is Hard to Find

Perhaps the most common reason we hear from companies that recognize the benefits of Elixir but decide not to adopt it is that they believe hiring Elixir engineers is too costly. And, for the most part, this has been true over time. It is also, however, a “chicken or the egg” causality dilemma (i.e. companies don’t want to hire when there isn’t a good amount of talent supply, talent doesn’t want to reskill when there aren’t a lot of jobs). That said, this is being addressed in a few ways.

DockYard has taken it upon itself to help train new Elixir developers through our DockYard Academy program. We plan to run three cohorts per year of 10 developers per cohort. If you’ve got enough fingers you can count that this is 30 developers per year. Code school attrition rates are typically high, between 25% - 50% so if we edge on the high side DockYard would be producing 15 new Elixir engineers a year. Which really is not a lot.

We recognize this, which is why we decided from the first day of working on DockYard Academy that all of our content would be 100% free under the MIT License. Any company can take our content and run their own training courses. Our best bet for addressing the Elixir talent shortage is to work together and not against one another when it comes to bringing more Elixir developers into the industry.

DockYard Academy has a focus on creating junior developers. However, that is mostly predicated on how long we believe it would take to get through the content. If you are a senior developer in another language I would expect you to get through the content much faster than our three-month cohort.

2. Talent is Expensive

Elixir finds itself towards the top of most salary surveys.

Every year when I see these come out I always see other Elixir devs cheering it on “Elixir devs get paid more!”. This is not something the Elixir ecosystem should be encouraging, as employers don’t see it the same way. They balance costs. So while Elixir can save on costs in one dimension, is it truly less expensive if the talent costs much more on average?

I actually believe that the cost of an Elixir developer at any talent level is about the same as similarly experienced talent in other languages. The difference is that Elixir is still extremely senior heavy. This is part of the reason why DockYard Academy is focused on producing junior developers with our guided cohorts. I believe we should start to see this number normalize at some point if we are producing enough junior Elixir developers.

Other Languages Have More “Off-the-Shelf” Tooling

Above I said and cited examples of why I believe Elixir is faster to develop software in than most other languages, but this only holds up in examples where you’re creating from scratch. It’s hard to compete against the sheer number of RubyGems or NPM Packages out there. We could get into a debate over how many of those libraries are actively maintained and are still viable today, but for the most part we can all agree there are more commodity-style drop-in libraries in those ecosystems.

This has been a known gap in Elixir for a while. In 2018 I ran an ecosystem survey to learn why companies decided against adopting Elixir. Beyond the talent question, the most common reason cited was because “X was available immediately in another language”. This brings costs down considerably, and more than wipes out whatever savings Elixir can show. Thankfully, in many cases, survey respondents mentioned what they wanted that they otherwise would have to create from scratch in Elixir.

While Phoenix has by far been the Killer App in Elixir for a number of years, Elixir needs to branch out beyond being seen as just a web framework language. At the time of this writing here is what is in active development:

• Machine Learning with Nx - See Jose’s blog post on the recent release of Bumblebee this is an extremely exciting space. And the pace of development is quickly catching up to Python, with hopes of surpassing it in many aspects. Elixir is well-suited for distributed Machine Learning solutions, which will produce order-of-magnitude performance improvements over the current generation of ML solutions.

• Native Applications with LiveView Native - This is a DockYard product. Think React Native on steroids. We have taken the proven LiveView programming model of moving stateful applications back to the server and rendering out client from the server over to native targets. Here is a comparison of where we could build Phoenix apps at the end of 2022 to where we expect to be able to build Phoenix apps in 2023:

These will be 100% native applications, not web apps. This is a huge value add with what will be surprisingly little work for developers. We are leaving the door open to other native platforms and we have potential solutions for offline mode as well.

• Modern Content Mangement with Beacon - This is a DockYard product. More often than not when an application that has been built in Phoneix needs some form of content management the solution has been to admin through Drupal or WordPress, then have Phoenix grab the rendered output and serve it up. This is less than ideal in many cases. Beacon aims to solve this problem once and for all. We’re hoping to re-launch DockYard.com as a Beacon-enabled LiveView CMS in 2023 alongside the v0.1 release of BeaconCMS itself. What is really cool is that we can leverage LiveView Native to serve native content to an application from BeaconCMS all built by marketing teams without the need for developers to get involved.

• Next Generation IoT development with Firefly - This is a DockYard product. Originally titled “Lumen” it is now called Firefly. Firefly will open up entirely new markets to Elixir development, specifically in the IoT space. Projects such as Nerves have been compiling the existing Elixir and BEAM for use on embedded systems. However, these end up being rather large in size, maybe 20+ MBs at least. Firefly is targeting WebAssembly compilation. We can then use WASI to compile into binaries meant to be run in server-side environments. Our hope is that we’ll see compiled targets well below 5 MBs in size. This may seem like a small difference, but when you’re a hardware manufacturer and memory-on-chip is one of your biggest cost considerations it adds up. Furthermore, Elixir is naturally well-suited to manage distributed IoT installations. We could take many of the pieces that Nerves has built over the past few years and create beautifully responsive UIs for low-powered environments using Scenic.

These are just what we have in store for what we expect to see released and at or nearly production-ready in 2023, all of which are going to be like developing in cheat mode.

Imagine being able to take all of the developer ergonimics and time reduction that Elixir provides and bring that to higher-level abstractions like what has been mentioned above. As companies are faced with growing cost concerns you would do well to start to consider Elixir as your company’s next technology direction.

If you’re ready to find out what Elixir can do for your digital product goals, get in touch and see how DockYard can accelerate your success.