Part 6: Drawbacks & Limitations

As always, use the right tool for the job. In my opinion, more often than not Elixir is the right tool, especially for web/API services. There are plenty of other areas Elixir excels, but there are also some things that are better suited for other languages, tools etc.

Not recommended

The rule of thumb I like to use is does it need to be lightweight or is it computationally expensive? If so, Erlang may not be a great fit because it does require the ErlangVM (BEAM) as mentioned before, which will definitely bloat the release and not be ideal for lightweight tools. Also, the high-level nature of Elixir/Erlang makes it great for expressing complex rules and abstractions, but not particularly great for low-level, efficient computation.

A few examples of projects to avoid using Elixir/Erlang for include:

  • CLI tools
  • Systems applications
  • Raw, low-level, computationally-expensive operations like image/video/audio processing or complex algorithms

I'm sure there are other examples, but in general there are some cases where something like Go or Rust may be more appropriate.

Drawbacks & Limitations

The biggest drawback to Elixir is not technical, it’s a lack of talent and expertise. Dynamic, immutable, purely-functional programming is typically a major departure from the established norms of Java, C

, Go and even Javascript to a degree. It’s not just a new language, it’s a new way of thinking, and a drastic one too.

With that said, Elixir isn’t necessarily hard or difficult to learn. It’s quite enjoyable to work with and you can get up to speed very quickly.

From a technical perspective, Elixir has few flaws, but because it does run on the ErlangVM it is not low-level like Rust or C. If you need lower-level, raw performance, you can write these services or APIs in other languages and still interface with them in Elixir, or just deploy them as a separate service.

Ops

The best way to handle Erlang in a modern ops environment is not entirely clear yet. Aside from some overlapping features and capabilities, Erlang wasn't designed with the 'disposable' mindset of today's ops best practices, especially when considering containers (Docker) and Kubernetes.

It’s not that it’s any more difficult to use Elixir with Docker/K8S environments, it’s just not clear if that’s the best approach. If all or the majority of your applications are written in an Elixir Umbrella application, you may not even need Docker or Kubernetes. I’m not sure how common that is and all of the advantages/disadvantages, but it could potentially simplify deployments and networking significantly, especially for small and medium-sized projects.

Gigalixir is a great PaaS solution for Elixir that takes advantage of some of these advanced capabilities while also drastically simplifying the process of setting up your system on something more complex, like AWS or GCP.

Lesser known strengths

There are also a few areas that may not immediately come to mind as a strength of Elixir/Erlang but actually are thanks to the terrific open-source community around Elixir:

  • Data pipelines via Broadway - Great for data engineering especially for concurrent producers & processing
  • IoT/Embedded via Nerves - For networked, 'heavy' IoT/embedded projects Nerves is an excellent option in Elixir, as long as you don't need raw, low-level performance
  • Databases and event streams - Some popular tools built in Erlang include RabbitMQ and Riak

Conclusion

Overall, Elixir/Erlang is an excellent option for most projects, and it is upfront and honest about its limitations. Aside from excelling at web, APIs and microservices, it also has advanced capabilities, especially Umbrella applications, that make it suitable for your 'home base', where you build the majority of your features and applications. You can reach for other alternatives, like Go or Rust, for CLI, System or compute-heavy services as needed, but these should become the exception rather than rule once you commit to Elixir as your default.