> I see a lot of pro-Erlang/Phoenix pushing in here, which is (as a polite reminder) an announcement about the rails framework. Not to say that one shouldn't, just that I think it's deviating from the main topic in hand.

You're right basically, but the migration wave from rails to phoenix has noticeably started, and it shows.

> Interestingly, I wanted to find out what's the real reason behind these pushes towards Erlang/Phoenix and I realised the discussion is mostly around how you can save a few bucks worth $20-50 by opting for a faster programming language.

Actually, the high performance stuff and Rails-y organization of phoenix is just something to give you immediate benefits and a sense of familiarity. It attracts people and give them a reason to try it out. Beginners praise it, but it's by far not the actual reason to keep pushing phoenix. Just like

"hey, it works like rails, you can do everything with it like rails does, so there is just a small learning curve and we have orders of magnitude better performance!"

> Any framework can be tuned to do anything.

Yes this is true. You can also write OOP assembly or use vim as a bitmap editor like paint. The point is: while you can theoretically do everything with mostly everything, the results will differ a lot and the way to these results will vary a lot.

With phoenix, there is no "magic" (people complain about this in rails!), everything is simple, explicit and straightforward. You also do not need many third-party tools like redis, sidekiq or memcached. This greatly simplifies the application code, reducing brittle constructs/bindings.

Currently, Rails still has the edge when it comes to gems, many things are readily available. This helps when "getting started" for typical app scenarios.

But a few weeks in, maintenance is the most important factor when it comes to development speed. Here Phoenix wins by a large margin. Less dependencies, easier code, less performance tuning, less bugs (compiler/dialyzer/... arguably).

> Rails right now is the only truly comprehensive framework with tight integrations to Coffee, LESS, CSS, etc.

The asset pipeline of rails can be quite a pain in the ass. Phoenix went a different way by integrating brunch, the probably easiest of the node.js task runners, which mostly doesn't even need custom configurations. (npm install --save brunch-less, your less files are integrated as you'd expect. Same for coffeescript, ...).

> If you run a business, then all this small talk shouldn't matter as much as how profitable you are. In the end, if your business failed because of your choice of framework (which usually reflects your philosophy), then you need to fix your business model and not the framework.

The development speed does matter. when you waste time optimizing things, fixing bugs with dependencies or stuff like that, you aren't shipping features. Moving fast is crucial for startups.

And then there is scaling. Phoenix is known to handle large loads with ease, and probably most startups can go a long way before they even have to consider horizontal scaling. Not having to think about this is worth more than the money you'd throw at servers to scale up rails (which, as you said, isn't needed in that quantity in phoenix either).

And just a personal note on top of this: Once functional programming/elixir "clicks" for you, translating business requirements into working code is so much easier as functional data transformation with pipes than having to deal with forests of class structures. For many cases, it just makes more sense (and is easier to read, maintain, extend and test).

---

Finally, the actual big win of phoenix is BEAM/OTP. Performance aside, the thought model of OTP just makes so much sense and simplifies building reliable, distributing systems a lot. I'd argue that OTP is the true reason people are blown away, elixir simplifies the syntax/reduces boilerplate, and phoenix on top makes getting started a breeze, looks like rails on the surface, and once you get into how OTP works, you're hooked.