Ask HN: Would you use Phoenix/Elixir for your SaaS startup? | Hacker News Reader

Ask HN: Would you use Phoenix/Elixir for your SaaS startup?

26 pointsantfarm24 comments

I wonder how people think about Phoenix Framework. Would you use it for your SaaS startup? Why? Why not?

Absolutely not. You get three "innovation tokens"[1] to spend on any startup and if you spend one of them on getting a team to learn Phoenix you're short-handed right out of the gate. Choosing boring technology allows you to focus on the business/problem domain you're trying to solve and allows you to find more qualified engineers to help you get there.

If we've learned anything from Facebook it's that you can start out with a pure LAMP stack and scale to billions of users with selective re-engineering later if there's a need to scale (Twitter proves something similar with Ruby on Rails; I'm sure there are "boring" Python examples as well).

[1] https://mcfunley.com/choose-boring-technology

Dropbox or Instagram might be good python examples

That's certainly an argument to be made, but I think you've overlooked the part where Erlang predates Rails by about two decades.

Erlang does, but Elixir and Phoenix don't.

Elixir and Erlang both yield BEAM bytecode, which is what actually runs. There's zero difference other than a choice in interface design, which is why they're also completely interoperable.

Phoenix is basically a feature wrapper around Cowboy which is written in Erlang and dates to 2011 when it reimplemented Webmachine which ran on Mochiweb which I am too lazy to dig up the actual start year for beyond "had quite an install base when Rails was in alpha."

Again, potentially useful argument, but you're pointing it in a direction that doesn't make any sense if you actually understand how those work.

One thing I’d like to note is that node is becoming a more ubiquitous stack. Don’t you think?

The tip says that you have to choose which is better for your team, which is very understood, no new technology, something which your team is almost senior. I work usually with people who has a lot of experience in Elixir and Erlang so, in my case, choose something like Python, Ruby or PHP is the wrong choice. You have always to check what is the knowledge of your team, the experience they have and then take a decision, but says "no" to a technology without checking the background of the team is a BIG mistake.

Our company has been using Phoenix/Elixir since day 1. Most of our engineers have experience using Rails and they are productive in less than a few days.

The Elixir community is strong and once a while when we have questions, we are able to get a quick answer from the community.

After building products from scratch using Rails (on LinkedIn mobile), Go, and Elixir, which each product has served over tens of millions of people, I am very pleased with the decision using Elixir which we spent the less time in scaling.

Happy to answer any questions.

My startup is build on Elixir for two reasons

1.) The nature of the problem (Distributed Multiplayer Game with complex logic but not computation heavy/number crunchy)

2.) I just like the language and have used it professionally for years

The value of #2 can't be overstated. In my experience, for some (most?) applications, the tech stack doesn't really matter. What tends to be more important is being comfortable with the language enough to iterate quickly and deliver value to customers

I'll build on this.

One thing I like about phoenix/elixir is that its as easy as a rails app to get started. The really cool thing is when you need some power/polish you can reach under the hood and do very powerful things with the BEAM.

My experience running rails apps at scale has been nothing but headaches when I do something concurrent or slightly weird in ruby. I always feel like I end up rewriting parts of the BEAM with redis/postgres

We built our online campaigning tool with a graphql phoenix backend

For our use case (burst of visitors staying for a minute) it served us well and we were quickly productive with it.

I ran/coded similar petition tools in rails and php, the concurrency level you achieve with elixir is an order of magnitude higher (or we became better ;)

https://github.com/TechToThePeople/proca-backend

Yes, and yes. In my point of view, the speed of development in Elixir/Phoenix is almost equivalent to that of Rails. And this is minus all the frustration of working with Ruby. Add on all the performance and language semantics of Elixir and you are far ahead already.

Rails can get you started quickly, and allows you to iterate quickly as well, but the way it slows down pisses me off. The only way to keep up is to keep feeding more and more beef.

The only negative I see with Elixir/Phoenix is that you'll have to figure out some things on your own until you arrive at a template for workflows you want to use in your app. After that it's all pretty smooth. A lot of people who have Rails experience don't seem to have any problem picking up Elixir/Phoenix

Would you use a pair of scissors for lawn maintenance? Sure, if my lawn was 1 square inch!

It depends on your specific use case! What are you building? Is this the best tool for the job?

Seriously these empty questions about using a tool for some general open ended purpose need to stop.

Use critical thinking. Research your issue.

Ask HN has become an exercise in handholding toddlers. I'm surprised this was even upvoted.

The question was not: "Should I use Phoenix/Elixir for my SaaS startup?".

I was interested in the broadest possible picture. Plus, I wanted to see how much interest there is at all for Phoenix/Elixir on HN.

If you feel offended by my question, please feel free to ignore it. Please don't shoot!

Yes and no. In my opinion Elixir/Phoenix can make you and your team productive from day 1. Phoenix is well designed (apart from few naming quirks and inconsistencies, but hey, which eco system doesn't have them) and Elixir is mature enough. Few years ago there was a problem with 3rd party libraries which were hobby projects, but never turned into proper OSS and were just abandoned - e.g. User Management library called Addict (https://github.com/trenpixster/addict). IMHO the community got much more mature now, so the problem is less apparent.

The argument for no, is the shortage of Elixir developers. I have a feeling that while it's easy to find node/java/c# devs - it is remarkably hard to find good Elixir developers.

If you have experience with it then yes.

Although, I work with Ruby for most of the time, Elixir is my "go to" language for all new projects.

I like it because of the speed and low resource consumption. If you don't have an experience with it then you would probably be better choosing known technology.

From my perspective, technology doesn't matter that much as we, engineers, would like it to be. What really matters is your ability to deliver product and your ability to market it.

As my experience shows you can even write your project with Lisp and if you're lucky enough ebay will buy it. Slack is written on php, so what? Should we all use php then?

When I started working on DynaBlogger (https://www.dynablogger.com) I picked Rails because that's what I've been using for many years. After one month or so into the development I tried Elixir and Phoenix and I seriously considered switching since I was still at the beginning. I liked response times in microseconds while with Rails you have to implement aggressive caching to achieve good enough performance. I liked the language and Phoenix too was nice, but eventually I decided to stick with Rails. The main reasons were 1) it was easy to get started but it would have taken quite a while for me to become as fluent with Elixir/Phoenix as with Ruby/Rails, 2) I would have had to reinvent several wheels from scratch or make do with inferior alternatives to popular Ruby gems. I didn't want to spend too much time with this then but I will likely revisit Elixir/Phoenix later, if needed for performance or else.

I think this is a good combination of language and framework but if you go that route you need to be sure you're ok with a smaller ecosystem, meaning that you may need to build things from scratch more often.

Yes. But only as an api. Elixir is a highly scalable and very productive programming language.I personally think its a better choice than nodejs, django or even GO.

I would not. I've experimented with it enough to know that I am much more comfortable executing with flask, rails, or dotnet. As a manager, I would dread trying to find engineers (I'm not in SV/SF), and I definitely would not want to build a product where everyone was learning the language/framework as we went (and everyone is thinking "re-write" before the first year has passed).

As others have said, if you're building a business, use what you know. Use what you can execute on the fastest, with the fewest unknowns, and with the most confidence.

Use whatever you know best. You can use all shell script if that solves the problem.

Elixir is cool but I don't think it can help especially when you're interested in getting your MVP fast. You can try to rewrite when the product is seeking to scale

Absolutely yes. My SaaS startup uses it, and it's really great.

I strongly disagree with the "innovation tokens" argument, at least as applied here. For one thing, while Elixir and Phoenix can certainly be considered "innovative" in the sense that they're better than more common alternatives, they really aren't "innovative" in the sense people sometimes try to scare you with—it's not all that different, on a fundamental level, than those alternatives. It feels very similar to Rails or Django—different in some ways, sure, but not at all alien.

But on a more fundamental level—all being well, this startup is something you're going to be doing for at least the next two or three years, and quite likely more. By far the most important factor in making technology decisions is going to be to use technologies that don't make you give up in frustration. Building a startup is a long hard journey, and yes, there will be many time along the way when you'll be tempted to throw in towel and give up.

If you're working day in and day out in a codebase, framework, language, or idiom that you don't enjoy, feeling that every day is a grind, then regardless of anything else you're chances of getting very far are less then they'd be otherwise.

So you're number one consideration when picking a language or a framework should be something that is a joy for you to use.

Of course, that's not to say productivity with he language (etc) is not important. Of course it's important! It's probably the most important factor that goes into that feeling of joy. That's why so many people love Rails… and that's also why so many people love Phoenix.

So go with it. Forcing yourself to use something that will be a slog for you to use is a fatal mistake for your startup—so go with what makes you feel comfortable and productive. If that's Phoenix, go for it!

My startup has been going for more than a year now, and in retrospect writing it in Elixir with Phoenix was absolutely the correct decision. I can say a lot of good things about it: it's comfortable, powerful, productive, efficient, and so forth. But most importantly, because of all these things, I'm not pulling my hair out. Yes, doing a startup is hard. But at the very least we can avoid making things worse by deciding that the things that are under our control (such as the framework and language to use) won't be adding to those headaches.

Maybe there are other languages and frameworks that are even better. Maybe that's true, although I do think that Phoenix is at the top of the list at the moment. Some people are already comfortable with Rails or the like, and prefer to stay with it. Sure, if that's the position that you're in, that may be the correct choice for you.

But as a general rule, the principle shouldn't be "avoid innovation", it should be to avoid getting stuck in a tech stack which will feel like a grind to work on a year from now.

If you or your engineers liked Rails, sure! Otherwise, namely at MVP stage, stick to whatever you guys are familiar with

I tried for ~18 months but eventually threw in the towel.

I was super impressed with Live View when it was first announced, so then I started building my app without Live View since at that point LV wasn't open source.

Things were moving along slowly but surely. It was slow for me because Elixir isn't the easiest language to learn if you're coming from Ruby or Python -- at least it wasn't for me.

Then LV went open source and got a few pre-1.0 versions under its belt. So then I decided to rewrite my app using LV. This was a grueling process because there's very little docs (at least 6-9 months ago in case things have changed), and almost no community resources around it. So I was asking a lot of questions and getting stuck but eventually I got most of it working (although it was in a very inefficient manner) with the help of a bunch of people who were kind enough to answer my questions.

I ran into issues left and right and ran into some really big concerns like not being able to detect if CSS or JS bundles changed on a LV driven page (I went all-in with LV and developed my whole site with it). So I opened a discussion about that and a few days later Phoenix and LV were patched to have that behavior which was an amazing turn around, so really, hats off to Jose and Chris.

But that really scared me a lot. It scared me because the CSS / JS bundle issue is something Turbolinks has solved like 5 years ago and it's something you would encounter when deploying your first application with LV. I didn't even get to the point where I was ready to deploy it, but I was getting close to MVP status so I was marking items off my check list.

What I'm getting at is, and maybe I'm totally off base here is that, if anyone on the core team were using LV in production then this issue would have been addressed long ago. It really shattered all and any confidence in using LV. I know as of today https://bytepack.io/ (Jose's SAAS app) is powered by LV, but it's being developed behind closed doors and seems to still be in a pre-shipped status so we don't really know what's happening there on the dev side of things or how the app looks and feels.

Also my app requires a decent amount of uploading and about a year ago uploads with LV were "on the horizon" according to the author of LV. It's now a year later and the latest 2020 ElixirConf keynote talked about file uploads. It's still not available yet and given my experience with the CSS / JS bundles, I'm not really sure how battle hardened the uploader will be initially. I know someone has to pioneer new features in production but I'm a firm believer that initial burden should be on the developers of the library. Sort of like how Rails usually fully bakes features into Basecamp for months before extracting them out into Rails so the community can test them.

It's nice to see the core team is building a real application using the technology they are developing. This is IMO why Rails is so successful (Basecamp was the focus from day 1). Phoenix IMO has a lot of catching up to to do and I hope one day it gets there because there's a lot of great things around the ecosystem of the language in general. However for now, I've stepped aside with intent to consider it again in a few years. It's unlikely I'd rewrite my current app in it then, but maybe the next one.

I hope no one takes this as a personal attack on Elixir and Phoenix. This has been my experience and I hope nothing but the best for Phoenix / LV in the future. I still do want to use it, eventually.

Also if anyone is wondering why I didn't just bail on LV and use Phoenix directly with "dead views", it's because I determined the juice wasn't worth the squeeze. A web server takes in HTTP requests and returns an HTTP response. We can do that in any modern framework and still get 100ms or less response times on low powered DigitalOcean servers without things becoming an infrastructure mess. Web server + background worker + Redis + Postgres can go a LONG ways in almost any stack. It seemed like I could get my app off the ground much faster using a language and framework I'm familiar in, with a much larger ecosystem of libraries to leverage.

Reply on news.ycombinator.com