
Ask HN: Would you use Phoenix/Elixir for your SaaS startup? - antfarm
I wonder how people think about Phoenix Framework. Would you use it for your SaaS startup? Why? Why not?
======
mikece
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](https://mcfunley.com/choose-boring-technology)

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

~~~
mikece
Erlang does, but Elixir and Phoenix don't.

~~~
gervu
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.

------
jerryluk
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.

------
grantjpowell
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

~~~
grantjpowell
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

------
tttp
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](https://github.com/TechToThePeople/proca-backend)

------
mrcnkoba
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](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.

------
princevegeta89
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

------
SkyLinx
When I started working on DynaBlogger
([https://www.dynablogger.com](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.

------
phanindra_veera
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.

------
gt565k
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.

~~~
antfarm
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!

------
oldprogrammer2
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.

------
achempion
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?

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

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

------
FBT
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.

------
Tolexx
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

------
nickjj
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/](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.

