That being said, I do miss active_support though; Elixir's utility libraries (fox, pipe, croma, etc.) doesn't yet have all the easy automagic that made rails so simple to develop on.
1) Referring to DHH and others as a "our old masters" instinctively bothered me.
2) While I appreciate that Elixir and Phoenix have Rails connections and can learn from it, I'd prefer it not become just a place for Rails refugees where it turns into a huge circle jerk about how Rails is terrible and Phoenix is great (which happens all too often in communities).
Other than that, I agree. But we should start something new.
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.
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?
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 Slides: 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.
I'll have a look at the slides
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.
And this works across the whole architecture. One of our projects right now is a mobile medical application for medical where caregivers communicate in real time with a number of patients. We have the mobile app talking to the server using a REST API and real time messaging for chat. The caregivers can communicate with the server using a web application with integrated web chat or via an XMPP client. And we have the normal public web and admin CRUD. All via a single server process in a single language. This is what Elixir/Phoenix was made for, it enables a new generation of modern apps.
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.
On the other hand, if you are just building another web app, Rails is the better choice...