WordPress database error: [Table 'patrickg_boffin.zph_ppress_meta_data' doesn't exist]
SELECT * FROM zph_ppress_meta_data WHERE meta_key = 'content_restrict_data'

Why you shouldn't use Elixir for your start-up | Boffinism

WordPress database error: [Table 'patrickg_boffin.zph_ppress_meta_data' doesn't exist]
SELECT * FROM zph_ppress_meta_data WHERE meta_key = 'content_restrict_data'

Skip to content

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

WordPress database error: [Table 'patrickg_boffin.zph_ppress_meta_data' doesn't exist]
SELECT * FROM zph_ppress_meta_data WHERE meta_key = 'content_restrict_data'

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


  1. Dave Newton 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 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.

  2. Joseph Martin Giralt 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 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 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.


        • Patrick 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.

          • Patrick 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.

          • Synth Slave Synth Slave

            Hi Patrick, thanks for the great article and also to Joseph for contributing a very informative debate on the pros and cons of using Elixir. I am a total newb to programming but am passionate about my startup so have been studying like a madman the basics (html,css,js) with Python/Ruby Rails and recently discovered functional programming and Agile philosophy, specifically from this old yet brilliant and funny hippy, Uncle Bob with cleancoders. My question to you (from a total newbie perspective) is isn’t it possible that it’s quality that matters, not quantity? Meaning that although there may be thousands more developers following one paradigm, if fewer developers are utilizing functional programming, then the chances are higher that you’ll have cleaner code that’s easier to debug vs spaghetti code that breaks when you chance one variable due to the state being able to change and/or from technical debt? Forgive me if I’m getting the exact wording wrong but I think you get the idea? If you have about 50 min to spare, Uncle bob has a great video where he comments on a real life scenario where a company just ends up hiring more and more developers to fix a problem which only compounds the problem (especially when developers leave) when fundamentally, the codebase is flawed. Anyways, thanks for reading and cheers for taking the time to write the article. Later, Cyrus

          • Smile Detox Smile Detox

            The number of users is not important at all. First take a look on JS community, a lot of developers doesn’t really help you. Secondly, even if there is only 16k users on elixir, they will help you in less than 10 minutes (on stackoverflow a lot of questions are solved in less than 2 minutes). Third there is a lot of project that use Elixir / Erlang to deals with complexes problems (Eg. WhatApps, Discord, Pinterest …).

            Your analysis only consider Elixir that is a bad choice, because when you use Elixir, you can use also Erlang. There is a lot of lib / projects that use Erlang (Eg. Facebook messenger). Someone that know Erlang also know somehow Elixir. Considering this, the community is not the same… The writing syntax is a small barrier for those people.

            I prefer a tiny community of experts to a large community of beginners (how many Java developers really understand Java? For example : small part of them know use Try/Catch will produce an overuse of the CPU memory).

            Currently, I’m working in company that create APIs. Elixir is certainly one of the best tech to use because a good Restful API is stateless so the functional programming deal perfectly with that. Take a look on Twitter and how they manage all the Tweets system. You will see they make a lot of middleware, database and tips to handle all of the tweets. With Elixir they could have only one solution.

            In your post you also consider company should use the same stack, if we analysis Blizzard (that is a huge video game company) they use a lot of technologies (Java, C#, C++, C, MySQL, Oracle, NodeJS, …), and they’re right, because they choose technologies depending of their needs.

            Of course, you should not use elixir for everything. It’s not a good choice for the following projet : (I don’t list everything)
            – Client side app
            – App for calculs (picture, sounds analysis …)
            – One off-script

            So use elixir for a startup is not a bad choice, it depends of your business and your needs (Eg. Discord use Elixir and scale to 5m concurrent users). And of course, you can use many technologies just be sure ever technologies that you use match perfectly your needs.

  3. Alchemist Camp Alchemist Camp

    Here is an alternate point of view: https://jaredfriedman.wordpress.com/2015/09/15/why-i-wouldnt-use-rails-for-a-new-company/

    Rails was a significant competitive advantage in its first 5-7 years and that helped Twitter, Airbnb, Groupon, Scribd, Soundcloud, Good Reads, Shopify, Indiegogo, Zendesk, and Github achieve substantial success. By my counting that’s 5 billion dollar companies and few IPOs. Scaling difficulties notwithstanding, there was nothing that could get startup to market faster than Rails could a decade ago. As Jared Friedman pointed out, they were also able to recruit substantially better talent *because* they were working with an exciting technology.

    However, he also pointed out that Rails no longer carries that advantage anymore. If you want a technological edge, you can’t simply use the most popular stack. It’s often better, especially for a startup which doesn’t need to hire thousands of engineers, to choose something the really smart people are gravitating towards. I believe Elixir absolutely is in that category and has been for a couple of years.

  4. iainduncan iainduncan

    If 37 Signals followed the advice here, there would be no Rails.

    • Patrick Gleeson Patrick Gleeson

      Thanks for your comment! To be fair, though, if you look at the history of 37 Signals, to be honest I think their story supports my point rather than refuting it.

      37S was founded in 1999 as a web design company, and was relatively successful. It was only in 2004 that they released their first product, Basecamp – and yes, at that point they adopted a fairly new and quite obscure programming language that wasn’t used very much for web, and built their own framework from scratch. They took a big gamble on a new technology and it paid off massively.

      But I would argue that the only reason they could afford to take such a gamble is that they already have 5 years worth of success as a company before that. Presumably they had cash in the bank, recurring revenue from clients, and weren’t betting the farm on Basecamp.

      This is why I ended the article with the point: “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.” I would argue that that is precisely the situation that 37S were in back in 2004.

      • iainduncan iainduncan

        Are you kidding? Five years as a consultancy is not an “established company”, that’s a baby. They were a tiny firm using new technology. RoR was a spinout from what they developed internally to be fast moving on new tech. They had been building what became rails for a long time before base camp was released. They were the antithesis of what you’re saying.

        • Patrick Gleeson Patrick Gleeson

          A long time before base camp was released? From DHH: “development for Rails started in the summer of 2003” (https://github.com/rails/rails/commit/db045dbbf60b53dbe013ef25554fd013baf88134 ).

          If you’ve been generating revenue for 4 years as a consultancy, and at that point you dip your toe into product development then I’d say you’re in a very different position to your average start-up that is from the outset betting everything they have on their core product. You can afford to take a much bigger risk on tech.

Comments are closed.

Notice: ob_end_flush(): failed to send buffer of zlib output compression (0) in /home/patrickg/boffinism.com/wp-includes/functions.php on line 4757