Deploying v0.11 Phoenix application to Heroku – My first ever blog post

True multiprocessing is cool. Imagine never having to deal with a task queue or worry about blocking in a controller again.

My ElixirConfEU talk should help answer these questions once it goes live in a few weeks. To answer them now, we have generators, like Rails, for scaffolding resources, except we split them into html and json. So you can do `mix phoenix.gen.html ...` to bootstrap a model, migrations, forms, templates, controller, etc, but you can also do `mix phoenix.gen.json ...` and it will do the same but bootstrap the controller and view for a JSON endpoint. We also ship with live-reloading in development, so you save your Elixir templates, css, js, etc, and the browser reloads/recompiles without a refresh. Outside of those things, our Channels layer that Rails is borrowing from makes it trivial for realtime clients. You don't have to worry about the transport layer (WebSocket/Longpolling/etc) and the client takes care of automatic reconnects. Once 1.1 ships, we also will support replaying missed messages b/w disconnects, which can be time consuming/tricky to get right on your own. Beyond what Phoenix offers, Elixir and OTP provide a distributed platform out of the box. So automatic failover, service distribution, clustering, are all baked in, which should be considered when evaluating X vs Y. Hope that helps!

Phoenix as a framework is on par with many frameworks in other languages as far as features. It shines in certain areas, such as websockets, because of Elixir/Erlang concurrency. The community is solid and Chris Mccord et al are doing a phenomenal job working on it.

However, I think the real benefit in using it would be in the Elixir language, BEAM VM, and the OTP framework. Once you get your head around the actor concurrency model and learn OTP, then you'll save time building concurrent (and parallel!), fault-tolerant, and scalable applications.