Elixir is already saving organizations like yours time and money. It can help you speed up feature releases, slash your server costs and more. Learn more in our free Ebook, The Business Value of Elixir, or get in touch today to learn how we put Elixir to work for businesses like yours.
As a developer, or someone who manages a team of developers, there are inherent advantages when you develop with Elixir and Phoenix.
You have every tool and resource to build performant and resilient web and native mobile applications, capable of handling huge influxes of users and scale without skipping a beat, while also spinning your entire software development lifecycle (SDLC) along at a faster clip.
But there is a wide gap between developing with Elixir and developing in Elixir.
The former involves stretching your development practices until you align with the “Elixir way” of designing applications. The latter means you’re treating Elixir like a “skin” for your IDE, changing the language but not your logic, which is a quick path toward creating unmaintainable code, actively harming the quality of your production apps, and hamstringing your productivity in the long haul.
Fortunately, at DockYard we’ve seen—and helped our partners fix—plenty of Elixir bad habits, and we have a list of common ones you can avoid in the first place:
1. You treat Elixir as simply a different syntax for accomplishing the same paradigms
The more development experience you have, somewhat paradoxically, the more likely you are to assume you can repeat the same paradigms and best practices you learned elsewhere in a new Elixir-based SDLC.
You might be extremely well-versed and skilled in writing applications using JavaScript, C, or Java, for example, but the common methods for approaching feature architecture are often fundamentally different in Elixir. You might be writing in Elixir, but you’re not moving with the language. The fact that no one, regardless of their professional experience, is safe from falling into this overconfidence trap, makes it all the more nefarious and potentially destructive.
As Elixir development consultants, we’ve seen this fallacy play out in every possible configuration. We’ve seen Engineers with decades of practical experiences in a myriad of languages approach Elixir as they would other languages, and therefore produce code that misses out on the strengths of Elixir.
In one example, we saw an implementation that was 180 lines of code in a complex business logic flow that required more than 60 logical jumps to understand. When we helped re-engineer this function to flow with Elixir, using idiomatic features such as the with statement and pattern matching, we reduced it to 25 LOC and a single logical leap.
When you apply this streamlining across your codebase, you unlock a massive efficiency gain that pays dividends for a long time. But when your overconfidence in the “old way” of building applications closes your eyes to how you could be developing smarter with Elixir, the opportunity costs accumulate into untenable actual costs, making your code difficult to understand and maintain.
You start to sacrifice performance and stability, then suddenly find that you’re stuck and need a brand new team to untangle your code and get your SLDC moving again.
2. Not learning the unknown unknowns of developing with Elixir
If overconfidence, driven by deep experience in other programming languages, is the root cause of most fraught Elixir-based SDLCs, then the path to resolution—and the second common pitfall—lies in a lack of Elixir education.
Developers have a sense they’re not developing in the best “Elixir way,” but don’t have the support needed to upskill in new best practices, paradigms, and application architectures. Leadership might not be making this educational effort feel urgent, rewarded, or beneficial for the organization, or they might not support it at all, prioritizing velocity over quality and continuous improvement.
The easiest way to shortcut your educational cycle (and fix some bugs while you’re at it) is to apply an open source static analysis tool like Credo . Credo goes beyond linting or code beautification to help teach you invaluable lessons about consistency using your own code.
Credo can help you refactor your code by highlighting unnecessarily complex fragments and escalating naming inconsistency, prioritizing issues based on their severity and location in your source code.
You can run Credo directly in your CLI using mix credo or integrate its engine with your favorite IDE/editor, like VSCode or IntelliJ. Once your SDLC around Elixir apps has matured, and your developers are all continuously curious and excited to squash more old habits, you can add custom checks that elevate your code quality and consistency in a way that feels less like a blocker and more like a helpful guardrail.
3. Not leveraging the ecosystem of code quality tools and resources
Whether you’ve just started with Credo or have built a library of custom rules for automating code consistency before you or developers even commit their work, there is still a massive ecosystem of untapped potential.
If you’re looking for next-lowest-hanging fruit on improving your Elixir codebase, check out these three resources and tools:
The native mix format command, which formats any *.{ex,exs} files in any number paths and patterns, based on formatting configuration at .formatter.exs. You can also configure mix format to run every time you save your file, depending on which IDE you use.
Doctests, which ensure documentation is a “first-class citizen” in your Elixir application. When you run your testing suite, doctests are extracted from the documentation you’ve added to the definitions of your functions and run against your code—not to replace other tests, but to make sure your documentation is valid and up-to-date.
The dialyzer discrepancy analyzer, which identifies type errors, unreachable code, unnecessary tests, and more. The Dialyxir project wraps around dialyzer to simplify its usage in an Elixir project
Faker helps you generate fake data to help run unit tests without manually creating a dataset or using data from production.
Technical resources are just the beginning. Elixir might not have the massive market- and mind-share of JavaScript/React and other frameworks for web/mobile app development, but its proponents are passionate and very willing, in the spirit of open source, to share what they’ve learned with others. There is an enormous—and always growing—ecosystem of videos, blog posts, code analyses, and educational opportunities to chase down more unknown unknowns and replace them with genuine Elixir know-how.
Our Elixir blogs are written for developers looking for practical Elixir solutions to meet the needs of their business, and the Elixir Radar newsletter will help you stay apprised of the latest news, events, and jobs in the Elixir world.
If you’re looking for a more holistic educational path, you can turn to the DockYard Academy open-source curriculum (or one of our cohorts) or the repository of videos from past ElixirConf events, which feature experts eager to discover even better “Elixir ways” of solving everyday challenges. ElixirConf 2023 wrapped up earlier this year, but there are plenty of other ongoing events and communities around the world.
You can, of course, always turn to the vibrant Elixir Forum for help and camaraderie.
4. Skipping over the built-in testing features of Elixir
We already talked about how Elixir makes documentation tests (doctests) a “first-class citizen” in the ecosystem, but doctests are only one part of Elixir’s comprehensive built-in unit testing framework called ExUnit. Unlike other web/mobile app development frameworks, you don’t have to worry about whether to use JavaScript or TypeScript, for example, to standardize and enforce types, or spend time searching for a discrete testing library to integrate into your existing codebase.
If you used mix new … to create your project, then you already have test helpers to get you going—no additional integration required. Once you’ve made one or more *_test.exs files in the test directory of your application, you can invoke mix test to run them in sequence and return a non-zero exit status if any fail.
If you’ve already containerized your Elixir applications for your CI/CD pipeline, you can integrate not only ExUnit tests, but also any mix format standards, Dialyzer, Credo, or other tests, into your pipeline and return the results to GitHub or another code collaboration platform.
Others have also experimented successfully with using Git hooks to run Elixir testing tools, like formatters or even Credo, as a pre-commit or pre-push task, catching issues immediately instead of having to wait for a notification down the road from CI that something was wrong.
5. Not using the Elixir ecosystem to kickstart big projects
Too many would-be Elixir developers, teams, and entire organizations are waylaid by making incorrect assumptions about what Elixir can’t do because the sheer market share of JavaScript and React drowns out Elixir’s use cases. Or they think a certain type of development happens only in a specific environment, like the tight integration between machine learning and Python.
In chasing the bandwagon, you miss out on vibrant and robust open-source projects that shortcut your path to production and align your codebase around Elixir today:
Native app development: LiveView Native Content management: Beacon IoT: Nerves Game Dev: ECSx Computational notebooks: Livebook Machine learning and data science: Bumblebee Numerical Elixir (Nx) Axon Scholar
When you use projects like these, all part of the growing Elixir/Phoenix ecosystem, to serve as the foundation for their applications, they access Elixir’s scalability, concurrency, and functionality without having to implement every piece of your applications entirely from scratch.
Avoiding the common pitfalls and missed opportunities of Elixir and Phoenix
Elixir is powerful and powerfully functional—as both a language and way of thinking. If you’re starting up a new project in Elixir for the first time, expect a few small growing pains, but know they’re all surmountable.
If you’re evaluating Elixir for your next big project, or feel like your Elixir-based SDLC is stalled out despite having talented developers at your side, there are plenty of opportunities to get the benefits rolling again:
- Ensure leadership is willing to try new development patterns
Adopting Elixir goes beyond technical changes—you may have to implement more robust (and slower) peer reviews, for example, to create consistency across your codebase or improve test coverage.
- Call out overconfidence—in yourself and others
If you’re willing to question assumptions and admit what you don’t know, you create opportunities to learn Elixir best practices and implement them for a stronger digital product.
- Take time for education and upskilling
If you’re a developer, spare some cycles for reading educational resources or watch videos about building with Elixir. If you’re managing others, recommend new resources to your team and block time after a release cycle to prioritize finding new improvements to implement next.
- Focus on deploying high-quality and rigorously-tested Elixir code
Prioritize making sure the benefits of Elixir—concurrency, scalability, and developer experience—come through across the SLDC. Sheer velocity will follow suit.
- Try peer programming to quickly upskill your development chops
More experienced Elixir developers can shortcut the path to learning the “Elixir way,” simplifying your code and making it immediately understandable for peer reviews and hand-offs.
- Get architectural reviews from Elixir consulting pros
At DockYard, we’re just one of many resources for teams eager to optimize the code they already have and create more impactful plans for the future.
If you’re still evaluating Elixir for your next project and are trying to understand the concrete value of often-intangible benefits, like scalability or developer experience, check out our Ebook, “The Business Value of Elixir.” You’ll walk away with real-world data, driven by experiences at organizations like Bleacher Report, on million-dollar bottom-line improvements driven by faster code and happier developers.
Now that you know where most teams fall into the trap of developing in Elixir, you’ve clarified your path toward developing with Elixir and driving massive organizational value with scalability, fault tolerance, and code clarity.
