Why Elixir Is the Best Language for Building a Bootstrapped, B2B SaaS in 2024
sleepeasy.appDisclaimer: 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.
Just my 2 cents!
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.)
Ah shoot, well then I'm sorry, that is unfair criticism on my part.
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.
No sweat, I get it! :D
Endorse 100%.
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.
The author does not own Petal Pro nor is he affiliated with it in any way.
> requires any kind of offline-enabled features
Considering it requires a server this is kind of a given right?
I am not your parent poster but I would interpret their comment as:
If you need offline mode you are better off disabling / removing the LiveView machinery in your Phoenix project.
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.
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.
I am probably getting annoying as this is my 3rd such post in this thread but... have you posted a job ad in ElixirForum?
Yes, that is how I found the engineers I did find. I wasn't impressed by the applications I got, although who I hired was fun and talented. If I remember they were either engineers who's primary projects were actually erlang, high priced agencies, people who were elixir curious, or people have only made pet projects.
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.
Yeah I agree with your last, it's true. Sorry that you didn't have better experience and I am fairly sure that I've seen your ad there and figured not to engage. :D
Though I think the biggest filter were the US working hours. I think Elixir devs are much more in the EU.
Also the Elixir slack has a well-watched #jobs channel, for other looking to post jobs
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
Sorry, I didn't mean built from scratch and scaled it all the way to unicorn. Rather worked on a unicorn scale app in some capacity. Even if you join a late stage startup and didn't build the foundation, the experience you get from how the org runs is pretty valuable.
Much easier to find a engineer who engaged with a large Python SaaS app than an Elixir engineer.
Ah I see, thanks for elaborating. Indeed, if you want someone with recent experience in the Elixir/Erlang/OTP ecosystem at massive scale you're probably looking at a much smaller candidate pool than {python/js/etc}
That resonates.
I’ve heard it this way: it’s not the language it’s the leverage.
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.
That does sound awful.
I moved from PHP/Laravel to Elixir/Phoenix about two years ago and I can't imagine using anything else these days.
Do you have experience with Ruby on Rails?
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've got in-depth experience with many Rails apps and quite a few Phoenix apps (and many other stacks). I used to agree with your opinion, though I think Rails no longer holds a massive edge. Phoenix is now just as effective at releasing real-world products especially run-of-the-mill web apps. And when things get complex after a bit of time (usually due to business logic evolving) - much more effective.
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.
> On the other hand Phoenix destroys Rails in any realtime scenario.
The Rails realtime story is going to be radically improved in Rails 8! I've been using the Turbo beta, and it is magical.
With 3 lines of code each, I made my index page, and show page live, and real-time updating.
I think Phoenix has something similar--perhaps it was the inspiration?
> I think Phoenix has something similar/
phoenix's channels (for realtime) is the only multiclustered websocket solution with long polling fallback that I know of that will scale to thousands of users out of the box. My startup uses websockets and its never been a bottleneck vs the headaches I've deal with doing similar stuff in nodejs. its just an absolute unit for doing realtime.
And now they have liveview which takes that and builds on it to accomplish magic.
rails has done great things but comparing it to phoenix on realtime stuff is like comparing a moped to an f16
> comparing it to phoenix on realtime stuff is like comparing a moped to an f16
Have you tested this? I ask because under the hood, Rails is using Faye, and Faye is using EventMachine.
About 10 years ago I load tested Faye vs. Node in a websocket scalability test for a websocket based chat app I was writing, that, funnily enough had a polling fallback. We had scalability needs up to around 10k or 20k simultaneous connections if I remember right and I wanted to know their ceilings before we wrote the real code and invested in either.
Faye kicked Node's butt on simultaneous connections and throughput. Node fell over while Faye was still going. Eventmachine, which Faye uses, can scale like nobody's business. It IS an F16.
I worked at a startup using rails. I also spent several years as a nodejs engineer.
I built my startup in elixir.
having experienced all 3, I can tell you in real world perfrmance, the metaphor is accurate. if you're boostrapping a startup and you need fast, stable websockets. elixir is the GOAT.
yeah, elixir is still going to destroy it at runtime. the concurrent story is even more important with the features you’re talking about and especially in that segment, it’s not even close.
can you give me example when phoenix destroys rails?
runtime performance for web requests absolutely demolishes rails. its not even close. I was seeing sub 10ms response times in developer mode. database queries end up being the overwhelming botteneck,
Then there's realtime. phoenix channels is the standard. everything else is a janky copy thats issing one or more factors that make it so good. elixir users lightweight threads so there's less overhead per connection which means you can run WAY more connections on a single machine. Live view takes this further but allocating a persistent process per user on which state can be synced to the frontend without writing ay javascript.
ruby on rails has more and better gems when your'e starting out but once you get some traction, maintenance on an elixir app is much easier due to it being functional.
I just don't understand this, the ergonomics are about the same. Phoenix was inspired by Rails and Elixir by Ruby, after all. I've also worked with both and I'd say it's a match in terms of productivity.
I love Elixir and the productivity is probably real, but one big thing I've learned as a senior dev was reflected well in a recent HN post
> Take the road most documented
https://news.ycombinator.com/item?id=39165328
Rails likely has an advantage of documentation given its age and all the major mature businesses using it like Shopify.
A lot of newer languages have documentation/blog posts that's heavily centered around starting out with a new project vs all the bugs with existing Github issues/stackoverflows and design considerations of the framework and 3rd party plugins being fully fleshed out.
> Take the road most documented
I don’t necessarily disagree with that statement.
But it can also lead you to use Java or C, because they are also massively documented & mature. And I don’t imagine that’s the desired outcome either.
When Shopify adopted Rails is was quite new technology though...So they literally didn't follow this advice. In fact the CEO was part of the Rails core team.
Here's a talk in 2008 by the CEO about their caching issues
https://www.infoq.com/presentations/lutke-rockstar-memcachin...
I've been using Rails since 2007 I'm familiar with what it was like back then.
I'm talking about 2024. I have a large tolerance for risk, and I'd be a risk taker for my own new projects or for a very early startup. Or if a tech offered something significantly new and better than the alternatives, like Rails did in 2007 vs PHP.
But now that I'm older, and I value getting things in front of customers with the minimum amount of bullshit. I'm not seeking out learning some fun tech purely for highs of a good fancy new language/framework (I've done that enough). I'd rather not chase down framework bugs. I want to google a bug and see 5 other people already had it.
I also started using Rails a long time ago (circa 2005), and I have become older too (46 years now).
But I must say I think there is not much bullshit, and quite a bit of stability, in what Elixir / Phoenix bring to the table (saying this after maintaining a production French state-owned service running on top of Elixir for more than 3 years now).
There are also not that much framework bugs, the level of retro-compatibility is huge compared to Ruby in particular (except for LiveView which is still a bit young, but the rest is ... quite stellar).
I quite find that I could use exactly your last paragraph to describe _why_ I wouldn't pick anything else than Elixir these days. The TCO is great, the maintenance story is remarkably stable at the moment etc.
Googling works decently well now with Elixir too, the community is mostly fairly responsive.
What makes you say that?
I think, once you learn both frameworks, they’re just about as productive as the other.
maybe in the "writing code" dimension. I would much much rather maintain code in elixir.
What took you away from Louisville (laravel as my tts heard it)?
I used it for 5ish years and never felt like I really understood the framework; there way too much magic going on.
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.
Livewire was rewritten once for V2 -> V3 iirc?
I'm glad you found something that works better for you, but I wouldn't say that not learning to use the framework (which you don't need to understand the internals for to use) automatically makes the other option better. It just means Elixir clicked for you better.
Laravel really forces you to do things the "Laravel way" and as soon as you try to step outside that box you run into tons of headaches along the way, and upgrades become painful. I haven't found that to be the case with Phoenix at all.
There's also lots of "magic" going in in Laravel behind the scenes and it can be pretty painful to try and figure out exactly why something happened.
Livewire was a mess over all. It had a lot of breaking changes along the way and performance was terrible for anything but the most basic tasks. The support was poor; the docs were alright at best, the screencasts were paid, and Caleb never showed his face in his own Discord, which was troublesome because there weren't enough people using it for the community to support each other. The weird bugs and behaviour were all over the place and the errors you received when you ran into one of them did nothing to help you track it down.
I guess to sum up my feelings: PHP was fine but Elixir did click better. Laravel is a black box and Phoenix is objectively a better framework.
How does LiveView compare to LiveWire?
Live View is SO much better it’s not even close. It’s faster, more reliable, easier to use, way less weird gotchas.
Since you left Laravel about two years ago you only used LiveWire v1, correct?
I haven't used it myself but apparently v3 solved plenty of weird gotchas.
The last Laravel project I used was using Livewire V2.
Not all of the problems were strictly "Livewire" problems, but also just the limitations of PHP. Having to send the state back and forward and rehydrate the state on the server on every request is just slow no matter what you do. Live View has an active process for every connected user that maintains state so you only have to send tiny little diff's back and forward.
Do LiveWire responses get so big that the size becomes an issue?
Haven't used either LiveWire or LiveViews seriously. Honestly trying to understand what you're saying.
I was under the impression LiveWire only sent the data for the component being updated so realistically the main issue is latency (just as with LiveViews).
I mean, sending 0.1kB vs 1kB is 10x worse but in practice this doesn't seem like it would have a real impact in UX for the majority of use cases.
Livewire has to send the full state of the request for the component. Search results is a good example where the state can start to get big. Once it hits the server re-hydrates the models. They are also HTTP requests which have some handshaking.
Live View only sends the diffs excuse the state lives in an active process on the server, and it uses web sockets which is much faster than http requests.
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".
(EDIT: To clarify, my comment is only a response to "not that easy to find Elixir devs for a startup")
---
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.
Isn't this concern independent of the language?
> 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.
Actually no it isn't, I was indeed mixing Elixir and non-Elixir concerns in one comment.
Did the parent comment get updated? It doesn't track to what you've put here.
No it hasn't. As I stated, I was only reacting to his "not that easy to find Elixir devs for a startup" is all.
It sounds like you just dont want to work at a startup? What does that have to do with elixir?
Yes I don't want to work for a startup and I stated as much didn't I? ;)
What it has to do with Elixir is that Elixir does not scale well with a number of programmers, and many startups go through periods of explosive growth of personnel. With Elixir that very rarely works well, 99% of the time IMO it does not. Adding more people does not increase productivity, it hurts it even.
Do you think that’s inherent to the language, or a result of common patterns?
How do other languages, like Python, scale better to more devs, besides more devs available? All that comes to mind immediately is modules in Elixir being globally available, but I’m genuinely curios about your experiences.
It's mostly related to the fact that Elixir code is very terse and easy to understand, and that if you put 100 devs on a singular Phoenix web/API project codebase they will be stepping on each others' toes all the time so they need to kind of take turns if they don't want the codebase to become a complete mess.
Thirdly, Elixir devs are on average quite senior in general (as they are usually refugees from other stacks) which lends itself to one-man armies very well in my almost 8 years of experience working with Elixir.
This doesn't track with my experience.
We scaled an org with both Ruby and Elixir (later, 1 of the 2 blessed languages) and there was no tangible difference in that way.
You could also scale in other ways like microservice. Elixir plays great in that world, as pretty much every language does.
Regarding one man armies. Usual way I've seen to scale is to find those one man armies and put less expensive Jr + mid engineers on their team and have them work together. I don't think that's an Elixir thing though.
I'm not trying to sell Elixir here. I think it has benefits in smaller org size that mellow out and equalize as a company grows. Also, startups should always work in whatever language is most comfortable to founding team.
Hard to argue against anecdotal evidence one way or the other -- my view is probably skewed because I usually avoid big companies.
RE: microservices, yep, that's one of the ways to scale Elixir teams to more people indeed.
RE: one-man armies, agreed.
> I'm not trying to sell Elixir here. I think it has benefits in smaller org size that mellow out and equalize as a company grows.
No worries, I am sold for 8 years now. ;)
And yes, the benefits kind of plateau from one dev count and up I found. That was kind of the core of my comment, too.
> Also, startups should always work in whatever language is most comfortable to founding team.
Oh, absolutely. I love Elixir a lot but won't shill for it if I find myself in a situation where it would be a bad choice. Plus in startups development speed is probably the biggest asset of the programmers so I am not judging. (Though I don't want to work for startups anymore.)
Is it any different than Ruby in this manner? I've worked at companies with 60 ruby engineers we do fine. It's called writing tests.
Does stepping on each other's toes happen, of course! but no worse than typescript, java, etc.
I don't buy this argument.
It's 50/50 and really depends on the people, this is just my 8-year old experience, I don't make it as an argument that's truthful beyond any doubt.
There is also the fact that the companies I chose to work with didn't want a lot of Elixir devs and we truly made miracles happen with teams of 2 to 8 people.
What is the best freely accessible Phoenix tutorial? I recently searched a bit, tried a bit, but then ran into a problem, that should not have happened according to the tutorial. I guess the tutorial was outdated (got the RoR vibes from years ago). I could not fix it, due to the lack of understanding of how Phoenix works and what it wants me to do. Gave up again (for the second time) on learning Phoenix. Is there an always kept up-to-date tutorial around somewhere? I might consider it again, since I want to learn what liveview and all that is really about and how well it can make web apps etc.
I would get it from the phoenix's beak honestly - https://hexdocs.pm/phoenix/overview.html
agreed, the phoenix dubs and guides are excellent.
for elixir books, i strongly recommend sasa juric’s elixir in action—it’s the best explanation of processes and genservers i’ve found.
Pragmatic studios has great Elixir and Phoenix courses, they upgrade the courses regularly and you get access to the new versions without extra costs.
> 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.
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.
Ya, I’ve given up trying to seriously introduce Erlang anywhere.
Lovely language whose community and vm taught me an absolute ton that still resonates with me today.
But for a bunch of “cats” that need to be herded, engineers tend to be fairly packish in some regards so looks like it’s Go, Java, Typescript, and TypeScript/HTML/CSS(in JS)/React for the foreseeable future
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].
[1] https://www.youtube.com/watch?v=HP86Svk4hzI
[2] https://dockyard.com/blog/2024/02/06/5-benefts-amplified-saw...
now this is what i’m talking about…
I overall agree with your sentiment (and this is not some bashing on Tyler's blog post by the way) - Elixir is good enough that we could focus on "Showing" instead of "Telling", at least that's what I'm trying to do more and more.
And the OP presentation about ML is spot on in that regard :-)
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)
Remember when they rewrote their app and blogged about it? I do!
It was a (slow) migration, though, not a rewrite from scratch. They kept shipping software.
Exactly my point. The way the vast majority of rewrites happen.
yep, that’s the right way to do it.
I shouldn’t, but all these posts read like distant history to me with Fog Creek gone.
As if source code rusted except in this case, Netscape's descendant did rust -- in a different way.
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.
I have hired elixir devs recently, even worse: onsite only, and couldn't help myself with all the applications. And it wasn't like when hiring JS devs that I had to weed out the majority of super-junior candidates first. All around the statement of "hard to find devs" doesn't hold anymore as it used to. Just as a data point. And from the community often a saying is that there aren't enough Elixir jobs to begin with, so thats another story.
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.
Unrelated to elixir, but a company I worked at used a legacy and niche programming language in a few of their older projects. Their hiring strategy was similar: have a few seasoned programmers and hire juniors that are willing to learn (and there wasnt' a shortage of these). Never had a problem.
Elixir devs are quite easy to find if you post a job ad on ElixirForum.
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.
The reply's asking if you need 100 devs, might not realize this article was about building SaaS apps.
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.
Good point. There seems to be a strong correlation between fast growth, lots of money and technically unpleasant environment/stacks.
I'll take quality of life over money any day, but I realize I'm in an extremely small minority.
> good luck logistically scaling a dev team from 2 founders to 100 devs
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 would be interested, if I could maybe learn from a more experienced Elixir dev on the job for a month or so (even for temporarily reduced pay while I am catching up). I am quite quick at picking up languages and have broad experience in many languages and their concepts. I imagine there are more people like me out there, who would be happy to learn something new on the job and a nice language like Elixir at that.
I don't think devs and talents are too hard to find, if you are willing to look and be flexible.
this doesn’t track with my experience. every time i’ve posted an elixir job we had at least a couple dozen qualified, experienced candidates and a fairly diverse applicant pool.
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.
Do you need 100 elixir devs? Or do you need 2 elixir devs and 98 developers?
We went through a round of recruiting (Elixir app here) and found that as reflected on the StackOverflow survey from last year, a lot of people are willing to learn Elixir at the moment.
We've had non senior people onboarded a few months and they are doing well with Elixir at the moment, fwiw!
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.
That really depends though. Part of the time you are right but there are legitimate businesses settings where not shipping by the end of next week can mean missing out on much-needed $50K or so revenue.
Often a feature pressure of "ship next week" is due to bad management and planning though. Often engineers already foresaw similar needs and were told no before. Then suddenly it is urgent.
> Often a feature pressure of "ship next week" is due to bad management and planning though
while thats usually true, it can also be a result of rapid customer feedback. what customers want might not be apparent till you put it in front of them. bad managers are one thing but if you're a startup, its more about responding to customer needs faster than the incumbent can.
I agree and that's why I no longer want to work for startups or any company with "urgency" culture.
my market was exactly this; tied to the start of the semester, if i missed shipping a feature my next shot at getting it used in production was months away. and basically if we missed the fall season it might as well have not even happened.
Ultimately it is yet another optimization problem. You have fixed dev time, a budget and some deadlines. If possible, try rewriting a component and measure the effort and benefits. We had PoC with deep rooted data issues. We knew throwing it away would set us back by a year but it just kept getting uglier by the day. We added a thin data validation API around it which started catching a good chunk of the data issues and let us deploy the PoC. We're now rewriting a new core with built in data validation and tons of performance and reliability improvements.
Well that is a good way to go about it. Direct frontal assault against legacy problem indeed very rarely works.
it’s kind of a matter of scope. you’ve got a team, at least a couple developers, rewriting a microservice that really needs an overhaul for performance? go for it.
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.)
Rebuilding an existing codebase in any other language would fit that argument as well.
yep, you’re absolutely correct on this point. there were technical reasons why i undertook the effort and why i chose elixir, but the truth is that the correct business decision would have been to keep going on our original stack.
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.
> but because the year and a half i spent reproducing functionality could have been spent adding new features
What would you have used instead?
Doesn't matter much, really, as long as it's something with a big ecosystem.
I assume the original language of the codebase
Thanks I was distracted and didn't get that
yeah in this case it was a ruby/rails/react/angular frankenapp that was very much guided by a big ball of mud pattern.
It has nothing to do with elixir and everything to do with you spending time on a rewrite instead of adding new stuff.
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.
lol no, it was not intended to be a humblebrag.
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.
They are doing this to recruit talent. That's the angle.
It is the Netflix playbook.
Casually dropping the "6 years ago" like it's irrelevant
> 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?
Have you seen lisp? To understand even a bit if that you’d have to be god level.
Not that gods don’t make mistakes. But I kind of see where they’re coming from.
> Have you seen lisp? To understand even a bit if that you’d have to be god level.
Are we talking about parenthesis here again?
It's easy to understand a well written Lisp codebase once you are familiar with its concepts. What you can't do is try to read it when all your prior programing exposure is from, say, the Algol language tree.
> Have you seen lisp?
Yes: https://aplaceofmind.notion.site/It-s-Lambdas-All-the-Way-Do...
> i rewrote my startups
Yeah, rewrites are bad, especially as a startup.
Django and Rails are by far the best for small projects. It's not close.
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.
fwiw Python also has pattern matching: https://benhoyt.com/writings/python-pattern-matching/
ruby does too. its not remotely the same
What are you saying isn’t the same? This is a very hostile, dismissive response when I was simply pointing out Python had a similar concept in the hopes it might help the person understand something they said confused them.
As far as I can tell all three languages, Python, Elixir, Ruby, have pattern matching and the matching can set variables. Python’s has a “match” keyword. I’m not as familiar with Ruby, but I know it uses “case”.
I like Elixir’s the best because it’s not just what I would call a fancy switch statement. You can use it on single lines and in function definitions. Someone else might like a different form of pattern matching better. It’s just an opinion.
Pattern matching is fundamental to programming in elixir/Erlang the way go channels are in Go and super clean metaprogramming interfaces are in Ruby or types are in Haskell etc, you can do those things in other languages but when it's fundamental to the design of the language itself it filters down (or up) to every layer, where it significantly impacts how useful/powerful it is.
Elixirs pattern matching is the one thing I wish every language had from day one. Besides maybe an Optional/Maybe concept for error handling / data enclosures.
It makes for some very readable code and encourages passing return values that are easily consumed in a simple/functional way. Not capturing random error objects or unpredictable data structures.
Although I'm biased towards functional style, even though I code JS/Ruby for a living.
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.
You know, you can get all of this in PHP and jQuery for probably half the effort.
the django admin panel alone makes it a better framework for a bootstrapped app
Psst... Elixir has this too :)
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.
> you're just deeply unserious about running a company
is this sarcasm? ecosystem matters for certain projects.
How did you miss PHP?
Just forgot about it... Big 6!
i still dont get it why people say elixir/phoenix is better than rails
people said that since phoenix incarnation I mean we still got to so everything on phoenix meanwhile on rails we have gem for everything