5 ms·
> 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, j
by anonyfox 10y ago
> 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.
- steveklabnik 10y agoI really like Elixir and Erlang, but haven't found he time to play with Phoenix. But... > You're right basically, but the migration wave from > rails to phoenix has noticeably started, and > it shows. People have previously said this about: * Clojure * Node * Go And lots of things before that.
- rdtsc 10y agoThere is a difference this time. Phoenix and Elixir was created specifically with an eye towards Ruby developers. Jose is working for a Ruby shop from what I understand. Go was C++ ++ or Java++ or Python++, Node was front-end brought to the backend kinds deal (or "you only need to know only language" deal). Clojure is an interesting one, but I haven't gotten much to play with it, so don't have much to say about it.
- sotojuan 10y agoClojure will never take off as a "Rails killer" because well, it's a Lisp. Sounds superficial but it's the truth. Also, from what I see it doesn't have an opinionated framework like Phoenix or Rails. That said, neither does Node.
- KurtMueller 10y agoThere's Luminus: http://www.luminusweb.net/ http://www.luminusweb.net/ And then there's its competitor, Arachne: http://arachne-framework.org/ http://arachne-framework.org/
- anonyfox 10y agoSure! But this time (tm) it's different. Phoenix is a direct drop-in replacement for rails, with a bunch of strong benefits on top. Getting productive for a rails developer should be 1-2 weeks max, since one already knows how the framework works conceptually. The truly cool stuff happens when one learns how stuff works beneath the surface. While you're around: Elixir/Erlang in itself is a rather slow language when it comes to number crunching performance. The canonical way currently is to write NIFs in C for these parts. But if this native code crashes, the reliability promise of BEAM goes out the window. For me it would make much more sense to write native extensions in Rust. Have you ever considered to include a plugin to "mix", Elixir's build tool, that allows one to ship Rust source files alongside the Elixir application, which then at compile time fetch a Rust compiler, compiles the code on the current platform and generates a NIF? This would be so huge.