3 ms·

Except Phoenix and Elixir are just faster out of the gate than Rails and Ruby! "tl;dr Phoenix showed 10.63x more throughput over Rails when performing the same

by xutopia 10y ago

Except Phoenix and Elixir are just faster out of the gate than Rails and Ruby! "tl;dr Phoenix showed 10.63x more throughput over Rails when performing the same task, with a fraction of CPU load" https://littlelines.com/blog/2014/07/08/elixir-vs-ruby-showdown-phoenix-vs-rails https://littlelines.com/blog/2014/07/08/elixir-vs-ruby-showd... You can tack on a Phoenix app on top of a Rails app's database and immediately get big improvements as Rails can be a bottleneck.

tarr11 10y ago
I briefly looked into this, but it looks like there are a few differences in ecto migrations which mean that it's not perfectly smooth to use the same database. Seems like you can choose either rails or ecto to manage DB migrations, but not use both simultaneously. This makes migrating to elixir more challenging.
- josevalim 10y ago
  I'd recommend setting the `:migration_source` in your Ecto repository configuration and picking a different table name than Rails. But be careful, having two different sources changing the same database can be a disaster waiting to happen.
falcolas 10y ago
> Except Phoenix and Elixir are just faster out of the gate than Rails and Ruby! Sure. So is Java, C#, C, C++, Haskell, Node.js, F#... I could go on. But let's be honest with each other here. What is the real chances that their speedups were really due to a computation bottleneck? And frankly, if it was due to a computation bottleneck, a language on the Beam VM was probably a bad choice. > get big improvements as Rails can be a bottleneck. Rails can be a bottleneck. It probably wasn't, though. I can (and have) take an average web app and short circuited a re-write by adding a few choice indexes to the DB. Or I could rearchitect it and move some data processing outside of the critical response sections and do the same. Or I could move a few choice resources onto CDNs and improve end user performance. Or do better compression on PNGs... Or change an O(n) function into a O(log(n)) function... The list of potential improvements that have nothing to do with the speed of the language in question is almost endless. Ruby and RoR are pretty easy to scale, and if I were a project manager, I would personally have a hard time justifying limiting my hiring pool for the sake of a mere 8x speedup (unless I was honestly operating at a really silly scale).
- segmondy 10y ago
  techempower benchmark even has PHP crushing elixir

by xutopia 10y ago

tarr11 10y ago

I briefly looked into this, but it looks like there are a few differences in ecto migrations which mean that it's not perfectly smooth to use the same database. Seems like you can choose either rails or ecto to manage DB migrations, but not use both simultaneously. This makes migrating to elixir more challenging.

josevalim 10y ago
I'd recommend setting the `:migration_source` in your Ecto repository configuration and picking a different table name than Rails. But be careful, having two different sources changing the same database can be a disaster waiting to happen.

falcolas 10y ago

> Except Phoenix and Elixir are just faster out of the gate than Rails and Ruby! Sure. So is Java, C#, C, C++, Haskell, Node.js, F#... I could go on. But let's be honest with each other here. What is the real chances that their speedups were really due to a computation bottleneck? And frankly, if it was due to a computation bottleneck, a language on the Beam VM was probably a bad choice. > get big improvements as Rails can be a bottleneck. Rails can be a bottleneck. It probably wasn't, though. I can (and have) take an average web app and short circuited a re-write by adding a few choice indexes to the DB. Or I could rearchitect it and move some data processing outside of the critical response sections and do the same. Or I could move a few choice resources onto CDNs and improve end user performance. Or do better compression on PNGs... Or change an O(n) function into a O(log(n)) function... The list of potential improvements that have nothing to do with the speed of the language in question is almost endless. Ruby and RoR are pretty easy to scale, and if I were a project manager, I would personally have a hard time justifying limiting my hiring pool for the sake of a mere 8x speedup (unless I was honestly operating at a really silly scale).

segmondy 10y ago
techempower benchmark even has PHP crushing elixir