Disclaimer: Elixir is extremely productive, Phoenix is outstanding, the community is world-class, and as a result of the Erlang VM / OTP / Beam you can remove whole parts of your traditional webstack. If you haven't tried it I cannot recommend it enough.
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.
I can't speak for Tyler (the author) but as someone who's worked with him and managed him for over 2 years, I'd say take Tyler at his word versus assigning malice to his writing.
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.
Author here! I've not been compensated by the Petal Pro devs at all. I've interacted with them exactly twice—once in support and once to submit the world's tiniest PR. I'm just a happy customer.
(If that's not enough, you can dig in to the Petal Components repo and see I'm not a contributor.)
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.
I love Elixir, but I have to disagree with the principal aspect of this post.
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.
I attempted an Elixir startup and found that it failed at both. The language was lovely to use and very smart.
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.
I remember interviewing at a place that hired close to 90 elixir engineers in 2 months (or so they said). That actually sounded like nightmare fuel to me (in any language) so I didn't pursue it further.
You make some good points that I don't want to detract from -- but isn't setting the bar for finding a dev at 'built and scaled a unicorn level app' a little high? Are there really that many of those
My current company uses Elixir so I've had to pick it up, and while I get the idea, man the compile times are just awful. Our full app takes a good 15 minutes to build locally. And I don't know why, but I've had so many times where the incremental build has become corrupt and it needs to rebuild everything.
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.
i have to be honest: as a lover of the language, and with due respect to the author, i’m really tired of these “why i picked elixir” takes extolling the same virtues (or some subset thereof) we’ve seen written up in darn near every introductory article on elixir for the last five or six years.
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?
Maybe it was true 6 years ago, but I'm currently playing with Elixir/Phoenix and I feel very productive, Phoenix is well design and adding new functionalities is not that hard and the code is easy to debug. On the other side, Elixir and Erlang are not that popular and every time I talk about it to other developers, they may have heard of it but can't talk about it, so it's probably not that easy to find devs for a startup. But the barrier to entry is probably what keeps the libraries well designed. For anyone interested in Elixir I would start with those books in this order "Elixir in Action", "Programming Ecto" and "Programming Phoenix Liveview".
Hey! I gave a talk at Code BEAM Europe this past year about our experience with a year of machine learning on the BEAM [1]. That is, the impact on our business of going 'all in' on Elixir from a more fragmented stack (Python for ML and ETL). We actually did this twice, once in 2020 from a JS front end/Elixir back end to LiveView, then again in 2022 for the ML/ETL stuff. We benefitted massively on both occasions. I recently sat down with Brian Cardarella at DockYard to talk about this and they wrote up some posts about it [2].
OP did say building a startup, not doing a rewrite of a relatively mature project which is always a danger zone with blaring red sirens regardless of language.
But it's good to be reminded I guess when new shiny things come across your sceen
Thanks for posting this, I’ve been having similar thoughts lately.
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)
Long story short from a business perspective - good luck logistically scaling a dev team from 2 founders to 100 devs as quickly as your app does. Elixir devs are hard to find and are expensive.
That's micro-shortsightedness. Lots of tools even OS utilities are being rewritten in a "better" language. It could be quite beneficial from a business perspective too if you're spending more time fixing issues than addressing new requirements.
It's like why I cleaned my butt with this less than popular toilet paper. Like, we get it. It actually was great maybe even better than the name brand one. But at the end of the day, you still gotta wipe.
I don't know if your post was a humble brag, but on Elixir + rewriting core code well, if I'm buying a software company and I know that the engineering team took their time to write good, maintainable code, that company is worth a lot more than if it the codebase is spaghetti quicksand.
> 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.
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.
honestly these sorts of sentiments (in the link) remind me of the "lisp gives you enlightenment, lisp is the language of gods" etc. that we've heard for decades. I love lisp, but come on, gods?
I'd agree, for 95% of projects. If you are serving web pages, or implementing something that doesn't have a lot of server side work in between requests, then sure, pick Rails.
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).
I am really missing out on the Elixir hype. And Phoenix has liveview, so the htmx hype gets multiplied with the Elixir hype?
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 it worth it to learn Elixir (including Phoenix, and I would guess some Postgres) to be able to rapidly build websites? My day job is mostly Go microservices, making anything this way takes a lot of time and doesn't really feel worth it for single-person projects.
It's neat that Django has that, I've toyed around with it, but for rapidly bootstrapping internal tools I still think Laravel does it better with either Nova, or these days preferably Filament.
Meh, if you're not building your b2b SaaS company on one of the big names (python, Java, ruby, go, javascript) in 2024 you're just deeply unserious about running a company. The language is the last of your problems.
bnchrch|2 years ago
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.
cancan|2 years ago
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!
s3cur3|2 years ago
(If that's not enough, you can dig in to the Petal Components repo and see I'm not a contributor.)
elbasti|2 years ago
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.
mhanberg|2 years ago
Aeolun|2 years ago
Considering it requires a server this is kind of a given right?
hansonkd|2 years ago
As an engineering leader what I look for when picking tooling for SaaS which essentially boils down to two things:
I attempted an Elixir startup and found that it failed at both. The language was lovely to use and very smart.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.
gregors|2 years ago
pdimitar|2 years ago
kylecazar|2 years ago
randrus|2 years ago
I’ve heard it this way: it’s not the language it’s the leverage.
dbbk|2 years ago
Coming from a PHP and Node background, I definitely miss the speed of development.
dmix|2 years ago
stanmancan|2 years ago
stanislavb|2 years ago
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.
unethical_ban|2 years ago
pier25|2 years ago
karmajunkie|2 years ago
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?
y04nn|2 years ago
cigrainger|2 years ago
[1] https://www.youtube.com/watch?v=HP86Svk4hzI
[2] https://dockyard.com/blog/2024/02/06/5-benefts-amplified-saw...
dmix|2 years ago
But it's good to be reminded I guess when new shiny things come across your sceen
pythonaut_16|2 years ago
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)
cpursley|2 years ago
mbesto|2 years ago
farhanhubble|2 years ago
dartos|2 years ago
sharts|2 years ago
pier25|2 years ago
What would you have used instead?
unknown|2 years ago
[deleted]
dudul|2 years ago
ken47|2 years ago
outside1234|2 years ago
It is the Netflix playbook.
hmmokidk|2 years ago
nonethewiser|2 years ago
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.
behnamoh|2 years ago
bcrosby95|2 years ago
Yeah, rewrites are bad, especially as a startup.
tschellenbach|2 years ago
sho|2 years ago
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).
3dpancake|2 years ago
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.
elicksaur|2 years ago
Zababa|2 years ago
MainlyMortal|2 years ago
[deleted]
phendrenad2|2 years ago
melon_taeppe|2 years ago
weatherlight|2 years ago
https://github.com/mojotech/torch
TheCapeGreek|2 years ago
unknown|2 years ago
[deleted]
voidfunc|2 years ago
cultofmetatron|2 years ago
is this sarcasm? ecosystem matters for certain projects.
calvinmorrison|2 years ago
firemelt|2 years ago
people said that since phoenix incarnation I mean we still got to so everything on phoenix meanwhile on rails we have gem for everything