4 ms·

Hypothetically speaking, why would you choose Phoenix over Rails for a new app?

colbyh 11y ago
Better for building out services. Parallel processing. The supervised process abstractions are incredibly powerful. If you're building another Twitter I would still use Rails. You'll be much more productive. On the other hand, if you need to run parallel tasks or have mission-critical (aka can't go down for anything) work to be done I think you'll find Elixir the perfect combination of Ruby's syntax and Erlang's power. Just my $.02 - I'm having a blast with Elixir at the moment.
- aaron-lebo 11y ago
  Nah, if you really are trying to build the next Twitter Rails is a poor choice for architectural and scaling reasons. No need to repeat Twitter's own mistakes. On the other hand, if you are just building another web app, Rails is the better choice...
  - colbyh 11y ago
    I mean, if you're building an app for Twitter scale on day one you're already doing something wrong. But yeah.
ghayes 11y ago
Phoenix shares many features with Ruby on Rails, e.g. a strong MVC model, an integrated ORM, a routing system, etc. What Phoenix on Elixir excels at is concurrency and distributed computing. For applications, this means you can have many active web sockets, for instance, where Rails applications tend to break down when you have too many active connections. Phoenix uses erlang processes for these tasks, which are lightweight and can number millions on a single machine. As an example, Heroku uses cowboy (the erlang web server that Phoenix uses) for load-balancing incoming connections to all Heroku applications. The erlang VM (BEAM) is great for these types of highly concurrent, highly available, distributed tasks. The original use case for erlang was highly available phone switching for Ericsson.
- agopaul 11y ago
  This is very interesting as Phoenix could become the next Rails. I loved Rails and ruby, for the most part, but ruby MRI still lack 'Native Threading', and Jruby isn't viable if you are using external C extensions. To overcome the lack, I've used Resque (or beanstalkd in PHP, which has the exact same problem) as a background job manager, but then I had to write my own layer and rely on the database to handle the 'job' result. Which parts of the framework leverage the concurrency model, other than the routing/request handling part?
  - oomkiller 11y ago
    The best example is probably channels. The framework doesn't really have to provide you anything for you to be able to use concurrency. For a personal example, I was able to use RethinkDB changefeeds easily with channels: https://github.com/bbhoss/elixir_friends/blob/master/web/channels/tweets_channel.ex#L17 https://github.com/bbhoss/elixir_friends/blob/master/web/cha... I just start another process when you join a channel, and that process sets up the changefeed and pushes changes to the client in the form of HTML, allowing messages to be received and processed by the channel. You can watch the full presentation here: https://www.youtube.com/watch?v=aWaleoYD1Ro https://www.youtube.com/watch?v=aWaleoYD1Ro Slides: http://www.slideshare.net/bbhoss/otp-phoenix-channels-rethinkdb http://www.slideshare.net/bbhoss/otp-phoenix-channels-rethin... Another example is sending email. In Rails, you need to have something like Sidekiq (or now Activejob) to be able to background the job so it doesn't block the response to the client. In Phoenix, you can simply spawn a process to do the work and move on. Sure, you might want a system like exq to keep track of things a bit better, but ultimately the concurrency primitives provides by Erlang/Elixir allow you to do everything you need.
  - agopaul 11y ago
    @oomkiller: again, so interesting, especially when used in combination with RethinkDB. I'll have a look at the slides
- nathan_long 11y ago
  Another example: I work on a Rails app where the user submits a request to us, and we have to talk to an API to respond. We can't afford to leave the connection open with the user, so we make them poll for results. My understanding is that the cheap processes of Elixir would mean we could just keep a connection open to that user if we wanted to. Similarly, no need for a background processing framework like ActiveJob; just use processes.

Better for building out services. Parallel processing. The supervised process abstractions are incredibly powerful. If you're building another Twitter I would still use Rails. You'll be much more productive. On the other hand, if you need to run parallel tasks or have mission-critical (aka can't go down for anything) work to be done I think you'll find Elixir the perfect combination of Ruby's syntax and Erlang's power. Just my $.02 - I'm having a blast with Elixir at the moment.

aaron-lebo 11y ago
Nah, if you really are trying to build the next Twitter Rails is a poor choice for architectural and scaling reasons. No need to repeat Twitter's own mistakes. On the other hand, if you are just building another web app, Rails is the better choice...
- colbyh 11y ago
  I mean, if you're building an app for Twitter scale on day one you're already doing something wrong. But yeah.

ghayes 11y ago

Phoenix shares many features with Ruby on Rails, e.g. a strong MVC model, an integrated ORM, a routing system, etc. What Phoenix on Elixir excels at is concurrency and distributed computing. For applications, this means you can have many active web sockets, for instance, where Rails applications tend to break down when you have too many active connections. Phoenix uses erlang processes for these tasks, which are lightweight and can number millions on a single machine. As an example, Heroku uses cowboy (the erlang web server that Phoenix uses) for load-balancing incoming connections to all Heroku applications. The erlang VM (BEAM) is great for these types of highly concurrent, highly available, distributed tasks. The original use case for erlang was highly available phone switching for Ericsson.

agopaul 11y ago
This is very interesting as Phoenix could become the next Rails. I loved Rails and ruby, for the most part, but ruby MRI still lack 'Native Threading', and Jruby isn't viable if you are using external C extensions. To overcome the lack, I've used Resque (or beanstalkd in PHP, which has the exact same problem) as a background job manager, but then I had to write my own layer and rely on the database to handle the 'job' result. Which parts of the framework leverage the concurrency model, other than the routing/request handling part?
- oomkiller 11y ago
  The best example is probably channels. The framework doesn't really have to provide you anything for you to be able to use concurrency. For a personal example, I was able to use RethinkDB changefeeds easily with channels: https://github.com/bbhoss/elixir_friends/blob/master/web/channels/tweets_channel.ex#L17 https://github.com/bbhoss/elixir_friends/blob/master/web/cha... I just start another process when you join a channel, and that process sets up the changefeed and pushes changes to the client in the form of HTML, allowing messages to be received and processed by the channel. You can watch the full presentation here: https://www.youtube.com/watch?v=aWaleoYD1Ro https://www.youtube.com/watch?v=aWaleoYD1Ro Slides: http://www.slideshare.net/bbhoss/otp-phoenix-channels-rethinkdb http://www.slideshare.net/bbhoss/otp-phoenix-channels-rethin... Another example is sending email. In Rails, you need to have something like Sidekiq (or now Activejob) to be able to background the job so it doesn't block the response to the client. In Phoenix, you can simply spawn a process to do the work and move on. Sure, you might want a system like exq to keep track of things a bit better, but ultimately the concurrency primitives provides by Erlang/Elixir allow you to do everything you need.
- agopaul 11y ago
  @oomkiller: again, so interesting, especially when used in combination with RethinkDB. I'll have a look at the slides
nathan_long 11y ago
Another example: I work on a Rails app where the user submits a request to us, and we have to talk to an API to respond. We can't afford to leave the connection open with the user, so we make them poll for results. My understanding is that the cheap processes of Elixir would mean we could just keep a connection open to that user if we wanted to. Similarly, no need for a background processing framework like ActiveJob; just use processes.