Number crunching still has to be dished off to something else like C, Rust or Go, though.
1) Elixir + Phoenix have some definite advantages when spawning asynchronous tasks (no external dependencies, it's in the language) and it runs reasonably quick.
2) Coding in Ruby on Rails is faster. An example, it's much easier to write queries in ActiveRecord than in Ecto, which is over engineered for the common needs of a web app. Queries, updates, transactions, everything are productivity killers there. For 99.9...% of the web apps it will be fast enough and the CPU will sit idle most of the time.
3) Django is as bad as Rails for concurrency and performances. The ORM is more verbose than ActiveRecord but luckily it's much closer to AR than to Ecto. The project structure is very loose compared to both Rails and Phoenix, which is bad for onboarding people coming from other Django projects ("ah, you put that there, why?")
My suggestions. If you know you're going to build a big application, scale it, etc, use Phoenix. Small to medium size: use Rails unless you're already a Python shop. In that case use Django. Smaller frameworks like Sinatra or Flask: it's not worth using them with the exception of very small applications that won't grow bigger. If they do you'll start adding components and turn them into an homegrown nightmare resembling the more polished Rails and Django.
I've found Ecto to be a productivity boon once I understood it, except for very small projects. For those, I reach for Rails just as you suggested.
My real productivity boost with Phoenix is that Elixir (or the Erlang VM, to be accurate) can take care of so many things I'd be dishing off to Redis, Sidekiq or other tools in a Rails app. That and the lack of surprises from metaprogramming or ActiveRecord default behaviors I haven't kept in mind while building.
The promise of a lean app with rails' ecosystem is too good to be true, and it is. It's so much easier to just start with rails from the beginning instead of slowly adding things piecemeal.
I still like sinatra and flask but they have one purpose: very very simple webapis, that's it. Nothing even remotely as complex as user sessions or forms.
I've been playing with Pheonix/Elixir here and there but I've never sat down and written a full app in it. I guess that's the future ultimately, at least for larger companies that need that performance.
My other strongest languages are Golang and JavaScript, so I'm used to (duck-)typed and untyped approaches, and I've never felt that Elixir was difficult to work with because of the lack of types. I've treated pattern-matching like type inference, and as long as you have guard clauses, the worst that can happen is a runtime error which you "let fail" anyway.
I guess the guard clauses are a bit of boilerplate, but I feel like these complaints have a different root. I just don't see it yet.
