Skip to content

Why you shouldn’t use Elixir for your start-up

Before I started at Think Smart, I did the rounds in the London start-up scene, looking for early-stage projects that had an interesting product proposition with interesting tech behind it.

On company I spoke to were launching an e-commerce venture that had a small range of products that it wanted to sell to a broad audience. I won’t go into the details, but they were working on the assumption that for any potential customer who visited their site, there would be one particular product from their range that would suit that customer best. So their website needed to first identify the best-fit product, and then sell it to the customer.

The founders had a little cash behind them, and had hired an agency to build their MVP. They were now looking for a CTO to take the agency’s work in-house, prior to their public launch. The agency had built the front end using React, used an open-source Rails engine for the actual online shop, and then a recommendation engine using Elixir and Phoenix.

I got in touch, and spoke to one of the founders, who was very optimistic about the future of the venture. Then I was passed over to the tech lead from the agency, who kicked my tyres over the phone, to assess whether I was technically competent to take over development. After half an hour of fairly informal coder-chat about my CV, I was given an opportunity to ask some questions. The one that leapt straight from my lips was, ‘So why did you choose Elixir for part of the back end, if you’d already committed to using Ruby for the rest?’

The tech lead gave me three reasons:

“We wanted to make sure we kept the recommendation engine separate from the e-commerce engine, and using a different tech stack enforces that. And we thought the recommendation logic would be well suited to a functional style, whereas it would all get a bit messy if it ended up inside an ActiveRecord model. And Elixir is a straightforward language – any developer worth their salt should be able to pick it up easily.”

Oh dear. What alarmed me about the response is that none of the above is a reason to use Elixir. At best, they’re reasons not not to use Elixir, which is a separate thing entirely. If you don’t have the discipline to keep your code modular without building each piece in a different language, then you’ve got serious problems. Likewise, if you’re writing primarily in Ruby/Rails, and you’ve got a piece of logic that you want to write in a functional style and not get tangled up in an ActiveRecord model… well, you could always just write it in a functional style and not put it in an ActiveRecord model.

But it’s the third reason that I have particular issues with. This idea that programming languages are all much of a muchness, and you can swap them out howsoever you please. After that conversation I spent a week or so trying to articulate why I think that’s not a sensible approach, and I think I can best sum it up with the following question:

“What are the top 5 architectural/structural mistakes that Elixir/Phoenix coders tend to make, and how can you avoid them?”

What’s notable about that question is that I suspect the agency tech lead would have been unable to answer it quickly. In fact, I suspect there are very few people in the world who would have an answer for it at all. The reason is that less than 2% of web developers use Elixir, according to the Stack Overflow 2017 developer survey. There are barely 4,000 questions on Stack Overflow tagged Elixir and only 400 tagged Phoenix – whereas Ruby and Rails have 180,000 and 280,000 respectively. Elixir/Phoenix simply doesn’t get enough use for the community at large to have definitively explored the pitfalls that the technology strays near.

Now, imagine asking any experienced Rails developer the same question about their technology. I can promise you they’ll have an answer. They’ll probably struggle to limit themselves to 5. (Let’s see… fat controllers, fat models, too-close coupling between controllers and views, cluttering up the global namespace with helpers, undisciplined use of the messy ActiveRecord API, controller specs, ad-hoc tasks shoved into lib/tasks, ad-hoc tasks shoved into migrations…).

And this stuff matters. Even though Rails is a more opinionated framework than most, every technology encourages a particular structure, a particular style, and the direction the technology pushes you in should always be treated with caution, because what works in some situations won’t work in others. If you get it wrong, you accumulate tech debt. If you accumulate tech debt, your velocity decreases. If your velocity decreases, your ability to respond to opportunities diminishes, your ability to push out new features diminishes, your ability to survive as a start-up diminishes.

Now, I’m not saying that you should only work with tried and tested technologies for a start-up. Not at all. You should work with the best tool for the job. If that’s Elixir and Phoenix, use Elixir and Phoenix. But you should be aware that the less established the technology, the higher risk it is. What I can’t abide is letting the natural magpie tendency to want to embrace the new and shiny overwhelm one to such an extent that one ignores that risk and hides behind utterly trite arguments such as the ones the agency tech lead offered me.

Does this create a Catch-22 for Elixir? If developers avoid it because it’s not firmly established it will never become firmly established, of course. But I’m not saying we should all avoid less established tech. I’m saying that if you work in an early-stage start-up you should avoid less established tech unless you have a damn good reason to use it. And given the wealth of established, powerful and versatile languages out there, the situations where a start-up is better off using Elixir/Phoenix than, say, Node/Express, Ruby/Rails, PHP/Laravel, Python/Django etc are few and far between. For the most part, we should be leaving the Elixirs, the Groovys, the Clojures of the programming world to the established companies that can afford to get some things wrong, to accumulate some tech debt, to experiment and fail in lower-stakes situations.


Like this post? Check out my book, Working With Coders: A Guide to Software Development for the Perplexed Non-Techie, out now in Kindle and paperback editions on Amazon (UK) (US).

Published inSoftware Development
  • Dave Newton

    So really it’s not “Why you shouldn’t use Elixir for your startup” at all. (Separately, lumping it in with Groovy and Clojure, both of which have been around for *years*, is unfair. And really, the risk of language/ecosystem choice is a *hugely* smaller risk than the startup as a while.)

    • Patrick

      Thanks for your comment! I stand by my original title. Ok so maybe technically it should be “Why you shouldn’t use Elixir for your startup except for in the particularly unlikely event that it genuinely solves a problem for you in a way that outweighs the risks of using a language with so little community knowledge build around it”. But maybe that’s a bit wordy.

      I guess the comparison with Groovy and Closure is more about the traction that Elixir has than anything else. There are very few developers who’d consider any of those languages their primary strength.

      I will, however, concede your last point, that there are so many other risks to being in a start-up that suffering tech debt down the line isn’t going to be the top of your priority list. But I think as developers we still have a responsibility to consider the long-term consequences of our tech choices _on the assumption that the company survives long enough for there to be a long-term_!

      Some great food for thought in your response, so thanks again.

  • Joseph Martin Giralt

    Except that Elixir is basically Erlang/OTP with some really awesome macos. 1) The BEAM is an engineering marvel. 2) The Open Telecom Platform has been around and in use since the late 90’s by Sony-Ericsson. This isn’t some podunk language framework that was created by some academic with no real world engineering experience while working on their doctoral thesis. This was developed by an established company for real world problems. And as for Elixir itself, quite a few consultancy shops have thrown their weight behind Elixir. (plataformatec, thoughtbot, and dockyard to name a few.)

    • Patrick

      Hi Joseph, thanks for your comment! I agree with everything you say, but to be honest I don’t think it detracts from my argument. I’m not claiming that Elixir isn’t awesome, or that it’s immature, flawed or not applicable to real-world problems. (Or “podunk” as you put it – great word!) The problem I’m pointing out isn’t with the language itself, it’s with the knowledge about how to work effectively in that language that exists in the developer community as a whole. The vast majority of developers haven’t built enough using Elixir to know what are the mistakes they should be avoiding, and that information isn’t readily accessible online because not enough people are building big real-world apps and blogging about the mistakes they made.

      Equally, the fact that big-ish players like thoughtbot and co are getting behind Elixir is great, because as consultancies they have the luxury of being able to play around with it and make some mistakes, which all goes towards building up the sort of knowledge that’s needed. The problem is that the vast majority of that knowledge is internal to those companies – what they’ve written online about it is great but not nearly enough. I don’t think Elixir will be viable for start-ups until the current generation of thoughtbot employees quit thoughtbot, start their own companies using their hard-won first-hand experience of building web-scale Elixir apps, hire a ton of other people to work with them on their Elixir apps, flood Stack Overflow with questions and answers, and in general get the crucial, rare knowledge about how to make maintainable Elixir apps out into the developer community more broadly.

      Don’t get me wrong, I *like* Elixir. I really do. I just don’t think the community knowledge about it is in place yet to sufficiently de-risk it in the context of a start-up.

      • Joseph Martin Giralt

        Elixir Devs don’t use stack overflow and that’s a cultural choice. If I have Elixir questions, I go here: https://elixirforum.com, or use the Elixir slack channel. Why?because there’s a robust community where that information is readily available and it’s very easy to ask follow up questions. Stack overflow isn’t the be-all-end-all repository for developer knowledge.

        The hardest part of the Elixir, isn’t the language itself, It’s learning OTP and that is by far much older that Rails or anything else on the market.

        Here’s a bunch of companies who currently use Elixir in production. I guarantee all of them are leveraging OTP.

        https://github.com/doomspork/elixir-companies

        • Patrick

          There are still only around 4k topics on elixirforum.com, of which (for a fair comparison) <1k are about Phoenix. Those numbers are around two orders of magnitude smaller than Ruby and Rails content on SO. Those numbers don't do anything to demonstrate that Elixir has the sort of community content critical mass I'm talking about.

          • Joseph Martin Giralt

            and of Slack? Theres 16k active users in the #general chat alone. This argument of there not being a community is kind of absurd. https://uploads.disquscdn.com/images/74b191d142194857ea035db495e62584359912faa1b58e2e1436eb8834e72b21.png

          • Patrick

            Coupla points in response to that. The first being: 16k is pretty tiny. There are over 7m users of Stack Overflow, of whom, for example, 32% use Python. Even if we assume that only 10% of SO’s users are active, you’re still demonstrating that Elixir’s community is more than an order of magnitude smaller than other languages.

            But my claim isn’t that there isn’t an Elixir community. That would be, as you say, absurd. My point is that if you can’t answer off the top of your head what are the top 5 architectural mistakes that a particular tech stack exposes you to, you’re taking a very serious risk in using that tech stack in a start-up, a risk that’s only justified in the extremely rare case that a particular tech stack solves a fundamental problem you have that other tech stacks won’t. The point of all this quantification of the number of developers is to point out that (a) it’s much harder to learn about the mistakes if the community is smaller (because people only talk about the _good_ as opposed to the _bad_ when they’re still in the defensive “us vs the world” mindset of a niche technology), and (b) that because about 1% of developers have worked with Elixir in the past, there’s a 99% chance that if you’re a startup CTO you haven’t worked with Elixir in the past, and therefore that choosing to use Elixir to build a startup with would be choosing to use a new tech stack to build a startup with. Which is rash.