But!
As a long-time Elixir Developer who has gladly used it to bootstrap many applications and companies, I have to say I think this article is actively harmful to the community.
It's an extremely thinly veiled sales pitch for their "Petal Pro" paid boilerplate.
At the same time, it does nothing to address the tradeoffs of certain features like Live View. Which for the record is a poor fit if your app suffers from client-side latency or requires any kind of offline-enabled features.
He's a powerhouse of a developer, loves, LOVES the ecosystem and has always wanted to give back as much as he could. He's submitted patches to the core, he did so much for our Elixir CI and felt bad not giving it back via open-sourcing it and then blogging on our platform.
Tyler was instrumental in many of our technical decisions at our company, and I can confidently say nothing he made us buy was unnecessary, and he often worked very hard to save us the smallest bit of money.
Just my 2 cents!
(If that's not enough, you can dig in to the Petal Components repo and see I'm not a contributor.)
The pitch was just so direct, coupled with the perfect topic of "Want to build a SaaS? Use Elixir" I would have assumed you owned the paid boilerplate you discussed.
I unfortunately can't edit the post but I upvoted this in the hopes that people see it.
The lack of discussion about LiveView tradeoffs is one of the few things I actively dislike about the Elixir community: and I love elixir and reach for it for almost everything.
Considering it requires a server this is kind of a given right?
If you need offline mode you are better off disabling / removing the LiveView machinery in your Phoenix project.
As an engineering leader what I look for when picking tooling for SaaS which essentially boils down to two things:
1) How expensive and difficult will it be to scale the Org.
2) How difficult will it be to implement product features.
But at the end of the day, you spend time and money reinventing solutions already solved in other frameworks which distract from the features of your product. Elixirs libraries are growing, but they have not reached parity to near drop-in solutions found in Django for instance.
Is Django the fastest in code execution? No. Is it the most elegant? No.
But there is an outstanding catalog of existing solutions and libraries out there that a junior engineer can pull from.
Developer velocity is so much faster with a well established framework. Easy to hire for. And you spend time implementing product features instead of reinventing engineering solutions. My ideal product development workflow is to implement in Django, find the bottlenecks (if any) and then specialize those flows.
Elixir is great and beautiful, but it was much more difficult to find engineers with experience in it. I really only found engineers that had a curiosity to use it or just started using it. I was never able to find an engineer that I could hire who built and scaled a Unicorn level app with it. Something quite common to find with Django.
I'm not saying to use Django. But when starting a project, I just ask that people look at how hard it will be to find someone to help you in the future and decide if you want to spend time building product value or spend time writing beautiful code.
The freelancers I hired had Elixir experience from a previous job, but we ended up figuring out a lot of stuff together. It was harder to just hand off requirements and expect it to be done.
Granted my budget wasn't very big and I limited my scope to those within the Americas due to working hour constraints.
But it is very different from hiring for Python which is very easy to get a reasonably priced agency or freelancer with years of experience very fast.
Much easier to find a engineer who engaged with a large Python SaaS app than an Elixir engineer.
I’ve heard it this way: it’s not the language it’s the leverage.
Coming from a PHP and Node background, I definitely miss the speed of development.
I've built apps both with Elixir/Phoenix and with Rails. Yes, the Elixir/Phoenix stack is amazing and is definitely superior over Rails in several ways; however, with regards to Bootstrapping and releasing a real-world app/business (web based), Rails is still the king.
The place where I feel Rails still holds an edge is the massive amount of gems available, but hex is absolutely catching up and I'm only running into missing packages/libraries when I'm doing "weirder" things these days. The ecosystem continues to evolve for the better. On the other hand Phoenix destroys Rails in any realtime scenario. Maybe those edge cases matter to your particular project then again maybe not.
I think, once you learn both frameworks, they’re just about as productive as the other.
What forced the switch was using Livewire; cool idea but horrible performance, poor documentation, no support, and constant rewrites. Knowing it was based off of Live View I looked into that and there was no going back.
it’s not that i think they’re wrong, at all. it’s just that they add nothing new to the conversation, they’re superficial, and frequently don’t go on to give a reader any idea of how the decision worked out.
here, i’ll start: i rewrote my startups platform in elixir about six years ago and it was a terrible business decision. not because elixir was bad —to the contrary, it was fantastic —but because the year and a half i spent reproducing functionality could have been spent adding new features that would have translated to new customers, and that would have translated to an additional million dollars when we eventually sold our bootstrapped business (obviously if i’m quibbling about a million bucks im not talking about a venture backed business here.)
in terms of scratching my intellectual itch it was great, but i can’t defend it from a business perspective and whenever somebody brings up the notion of rewriting a core platform i tell this story.
now can someone please write some elixir articles about cool stuff they did with it and get those on the front page?
---
I don't speak for anyone except myself and a few acquaintances but I wouldn't accept an offer to work on a startup with Elixir unless we're talking at least $15,000 a month or more. And even then it depends a lot on team and company culture. I am tired of sprinting without that ever being connected to me getting extra cash or even recognition.
Elixir and Phoenix are productive as hell but they also need deliberate approach and not everything should be done quickly. Requiring me to churn out 3-5 features a week in the first 6 months is the best way for me to hand my resignation a mere two weeks after starting.
Sorry, you might not have had this in mind, I am just reacting to your text.
But rest assured, ElixirForum has quite a few people who would grab an Elixir job if given the opportunity, some for as low as $2500 a month even. And most people frequenting the forum mostly check its own Jobs section. So if you really want to widen your options, definitely make a job ad post there.
This was the exact issue we encountered after I had switched a startup's backend from Node to Elixir. I was able to churn out features pretty quickly (and the switch itself turned the core batch job underlying the product from a multi-hour runtime to less than a minute), but the bus factor was pretty much 1 and we were never able to really increase that before the company ended up running out of runway and folding.
This was almost a decade ago, though, so things have hopefully improved somewhat.
[1] https://www.youtube.com/watch?v=HP86Svk4hzI
[2] https://dockyard.com/blog/2024/02/06/5-benefts-amplified-saw...
But it's good to be reminded I guess when new shiny things come across your sceen
Elixir is extremely overhyped, not because it’s not great but because most of the discourse is about how much better it is than other languages.
With Python, Rust, Go, and JavaScript I can find a ton of interesting projects and tools; tons and tons of examples of people doing interesting things, easily outweighing the language hype.
Elixir has a handful of core tools, tons of hype posting, and a smattering of introductory blog posts to those tools.
The community really has the appearance of lacking depth. (Granted I think partly that’s because the depth exists inside companies that don’t really talk about it)
Having said that, a single team of seasoned Elixir devs can achieve more/better things than 100 average devs using the usual SPA/API/microservices-JS hell with all that modern unneccessary complexity. Saying this as a former DevOps guy babysitting the mess of multiple of these teams before.
Another good thing about Elixir is that the odds of you actually needing 100 devs coding in it are close to zero. I've been in financial EU startups that moved tens of millions a month (they were not huge) with the grand total of 4 devs. The only problem was clearing up customer requirements (i.e. our product people dropped the ball and left us doing most of their work).
And expensive? Yeah but I wouldn't be against that if I was an informed business owner. Most Elixir devs are refugees from other tech stacks and are quite senior. Good talent should be compensated well.
Having worked at multiple unicorn+ SaaS products, the product feature demands are significant.
Yes if you have one sole feature that you can pour all your engineering resources into like whatsapp delivering messages then it makes sense you might get away with 2 Elixir devs.
If you are working at a unicorn who just raised $250m in founding and now has to deliver 100 new features this year... well the elegance of the language won't help as much as you think.
You'll never need 100 devs to work on a single elixir project. I as a solo dev built out the backend for my startup to profitable. We keep discussing bringing on a new developer during the occasional crunch but its been 5 years of operation and we haven't really needed it aside from increasing the bus factor. features go out fast enough as is. elixir is very productive.
based on my experience, if you need more than 5 developers, you should separate out features to independent systems and have them communicate with each other over established interfaces. Then you can use the language specialized to the task at hand. Either way, 100 engineers on a single codebase is not going to be efficient no matter what language you are working in.
That said, this article is about startup. the name of the game is to crank out features and aquire users. elixir is performant enough that you're not blowing your budget on cloud infrastructure and high level enough that you can build out and maintain your mvp with a skeleton crew.
If you run into a situation where you suddenly need to scale to 100 engineers, thats a great problem. it means you have revenue.
I don't think devs and talents are too hard to find, if you are willing to look and be flexible.
you just have to post where they are. i strongly recommend the newsletters, the jobs channel on the elixir slack, and elixirforums. all great resources.
We've had non senior people onboarded a few months and they are doing well with Elixir at the moment, fwiw!
you’re a solo developer rewriting the fundamental application your company sells and depends on for revenue? yeah, maybe not so much. (actually there’s no maybe about it. don’t do this.)
What would you have used instead?
i’d love to say you were correct, and if it was a tech acquisition you might be right. in our case they were acquiring our customers and goodwill primarily. the app was sunset a year later.
It is the Netflix playbook.
I dont know… we cant expect each article to expand on the previous article you read. i dont think article writers should scrap their article if it doesnt contribute some novel benefit. I think one additional article without new points simply emphasizes those existing points.
I mean, I get your fatigue. I just dont think there is any fault here.
Not that gods don’t make mistakes. But I kind of see where they’re coming from.
Yeah, rewrites are bad, especially as a startup.
But if you do have something active running on the server - ingesting something, holding connections open, talking independently to other systems, anything soft real time - you will very quickly run into the limits of pure web frameworks and will be forced to re-invent all manner of wheels and end up building much more than you need to. That's where elixir shines and is, IMO, the optimum choice.
Phoenix is basically "rails for when you actually need something more than build the world/destroy the world web requests". It's great for that, and those kind of projects are more interesting IMO, too. But for anything else, use Rails (or, yes, Django).
This article provides a huge list of things you have to know for web dev. Certainly not all of them a required. And of the ones you will have to know to accomplish your task, you'll still have to learn the Elixir flavor of it.
My current job is rewriting what is basically a crud elixir app in python for a company. I'm not completely sure their reasons wanting it re-written, but they're spending money to do it, so they must have some justification. I have heard them mention difficulty in finding people to work on their existing codebase. A lot of companies they just want fungible (and cheap) programmers (like me).
I've really only bothered to learn enough elixir to reverse engineer the existing app for reference. I have no idea what good elixir looks like, and it could be that this is just bad elixir. Completely subjective, but it's not easy to follow. I had to work through some code where a bunch of functions were piped together, but all these functions were defined multiple times with different args (pattern matching on arguments). It seems like a strange way to do flow control within a pipeline, because the logic seems to really be spread around.
Maybe I have to sit down and write something from scratch to appreciate it.
is this sarcasm? ecosystem matters for certain projects.
people said that since phoenix incarnation I mean we still got to so everything on phoenix meanwhile on rails we have gem for everything