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, jus

by neya 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. 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. Any framework can be tuned to do anything. Rails right now is the only truly comprehensive framework with tight integrations to Coffee, LESS, CSS, etc. As someone who is writing his own framework in Scala, I learned this the hard way after under-estimating how much of work is already done for you in Rails. 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. As a polite reminder, I'd like to link to an old comment of mine I made at the time of Rails 4.2: https://news.ycombinator.com/item?id=8201244 https://news.ycombinator.com/item?id=8201244 Have a great weekend everyone!

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 ago
  I 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 ago
    There 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 ago
      Clojure 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 ago
        There'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 ago
    Sure! 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.
vidarh 10y ago
I personally dislike Rails quite a bit, but I still agree with you. Personally I think the main choice of language and framework for web sites should be down to what you can easily hire developers that will be happy for. I've chosen PHP for that in the past despite detesting it, at a time when Rails did not have enough of an eco-system. I might pick Rails now, even if I personally dislike it. I'd be concerned with niche alternatives out of consideration for whether or not I'd be able to hire replacements/additions. Speed concerns would be extremely far down the list... I have worked on systems where speed for some APIs would necessitate something else, but it is very rarely the case for web apps. I also do devops consulting, and at least for my customers it is extremely rare for the dynamic parts of the web frontends to make up sufficiently large portions of the overall hosting costs to be worth worrying about. In the rare instances it is, it usually turns out that people have used a non-standard setup letting Rails serve up static content too, and/or have not made any attempt at doing even basic caching. Doesn't mean you shouldn't consider something else than Rails. I personally rarely use Rails if I can avoid it. But most of the reasons for picking one of the other are excuses to obscure personal preference. Personal preference is fine. It's a perfectly good reason to want one over the other, as long as it meets other needs. But people should realise it rarely actually makes that much difference, so unless you have very specific use cases and benchmarks to back it up, I'll think it's a bullshit excuse if someone comes to me and says they need X because of speed (in the context of web apps).
- dogweather 10y ago
  The biggest difference I'm seeking is quality of life.

by neya 10y ago

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 ago
I 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 ago
  There 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 ago
    Clojure 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 ago
      There'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 ago
  Sure! 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.

vidarh 10y ago

I personally dislike Rails quite a bit, but I still agree with you. Personally I think the main choice of language and framework for web sites should be down to what you can easily hire developers that will be happy for. I've chosen PHP for that in the past despite detesting it, at a time when Rails did not have enough of an eco-system. I might pick Rails now, even if I personally dislike it. I'd be concerned with niche alternatives out of consideration for whether or not I'd be able to hire replacements/additions. Speed concerns would be extremely far down the list... I have worked on systems where speed for some APIs would necessitate something else, but it is very rarely the case for web apps. I also do devops consulting, and at least for my customers it is extremely rare for the dynamic parts of the web frontends to make up sufficiently large portions of the overall hosting costs to be worth worrying about. In the rare instances it is, it usually turns out that people have used a non-standard setup letting Rails serve up static content too, and/or have not made any attempt at doing even basic caching. Doesn't mean you shouldn't consider something else than Rails. I personally rarely use Rails if I can avoid it. But most of the reasons for picking one of the other are excuses to obscure personal preference. Personal preference is fine. It's a perfectly good reason to want one over the other, as long as it meets other needs. But people should realise it rarely actually makes that much difference, so unless you have very specific use cases and benchmarks to back it up, I'll think it's a bullshit excuse if someone comes to me and says they need X because of speed (in the context of web apps).

dogweather 10y ago
The biggest difference I'm seeking is quality of life.