Rails vs. Phoenix
Over the past week I’ve been diving into Elixir and Phoenix. As it is with most languages, there some good and some bad with Elixir. That said, anyone announcing the death of Rails at the hands of Phoenix is probably a bit early.
While I didn’t do any benchmarks myself, that path is well worn. It seems fair to say that Elixir is probably faster than Ruby and Phoenix is probably significantly faster than Rails.
It’s also likely that Phoenix will handle WebSockets far better than Rails will, even with ActionCable.
On top of all of that, Elixir seems to also have a slight edge over Rails in terms of asynchronous jobs, since they can be done directly. For truly heavy jobs, Elixir would also likely need a library of some sort to manage load generated on non-Elixir systems (like your database). It seems like it would be a thinner layer between your transactional code and your jobs, though.
Despite all of that, if I were starting a new project today, odds are good that it wouldn’t be in Elixir or Phoenix.
There are exceptions. If the project had a heavy reliance on realtime web interfaces or an obvious performance bottleneck at the root of the problem I was trying to solve, those would be great use-cases for Elixir1.
So if Elixir and Phoenix perform better and make realtime interfaces easy, why not use it?
The reason people use Rails2 is that the code is simple to understand and reason about when written well. Elixir’s syntax seems to encourage and reward “clever” coding practices. In languages like Ruby and Python, expert level developers will tend to write code more easily understood by beginners3. In Elixir the opposite seems to be true.
With Elixir’s powerful metaprogramming facilities, it’s possible that future version of Phoenix might be able to approach the ease of understanding that Rails has achieved, but it’s definitely not there yet.