Can you give a briefish but honest assessment about how Phoenix outdoes going with your stock Rails stack, and how it might make a few things harder? How would I differentiate/"sell" an Elixir/Phoenix stack (say, for an API) to a manager? How does Phoenix differentiate itself from Rails, and how difficult is it to switch, and under what circumstances?
(I say this as a fan, btw! I just think that it's important to get the pros and cons out there. I also think that a lot of Ruby/Rails folks are VERY curious about Elixir generally and Phoenix specifically, lately...)
Sure. So let me start by saying I have worked full-time in Ruby/Rails at a Rails shop for the last four years. Phoenix is derived from that experience, and we borrow some great ideas from Rails.
Pro - Concurrency:
I really love Ruby/Rails, but what led me to Elixir in the first place was constantly dealing with lack of concurrency in Rails and being unable to do anything like websockets in a sane way. For example, in Rails we can't really block in the controller without killing throughput, so we go to great lengths to background everything. This makes simple problems like "Make a remote API request through a controller" way harder since we now have to throw it in a worker queue, then poll from the client on the status of the job, then finally return the result. In Elixir/Phoenix, we can block in controllers without a blip on throughput, do our work, and return the response.
Pro - Error Handling / Fault tolerance
I won't go into too much details here, but the Erlang/OTP way of building applications around Supervisors and responding to failures has really blown me away. Erlangers have been sitting on this innovation for the last couple decades so it's battle tested and has proven its merits. Look at WhatsApp, 1-2 million connections per server, 400 million users ~ 30 engineers.
Pro - "Realtime" / pubsub:
Phoenix also ships with a realtime layer that we call "Channels" for doing pubsub/realtime events to clients. Our goal is to make building realtime applications as straight forward as building REST endpoints. We include a `phoenix.js` browser client, but we are targeting multiplatorm support and have a working Swift client internally. So Phoenix aims to go beyond a typical "Web Framework". The Web is more than just html apps (but Phoenix excels as just that). Imagine a iOS game publishing on Phoenix channels to other iOS clients, and a Web front-end reporting world events, player lists, etc. Phoenix can power all of it. By virtue of the Erlang VM, we also get cluster support For Free. You can run multiple phoenix nodes on a cluster and PubSub Just Works. No need for redis in b/w or worrying about sticky sessions. Concurrency in Elixir is location transparent. A process is a process regardless of machine it runs on in a cluster.
Cons - Packages, Training:
My goals are to wholesale replace all my Rails work with Phoenix, but obviously we have a ways to go. The main cons are lack of off-the-shelf community packages like in Rails land. We are also not yet at 1.0, so you have to be willing to put up with breaking changes until we're ready to brand a 1.0 release next year. I'm using it for prod systems, but this is an upfront reality as we march towards 1.0. Other cons would be having to train folks new to Elixir, which often means learning a number of new paradigms at the same time. There's a helpful Elixir community for newcomers, but it will take more upfront work to get up to speed if you're coming from an OO background.
Nice work! I would also recommend stealing as much good stuff as you can from ChicagoBoss. It has the same RoR roots and great overall architecture. Thanks for this.
(I say this as a fan, btw! I just think that it's important to get the pros and cons out there. I also think that a lot of Ruby/Rails folks are VERY curious about Elixir generally and Phoenix specifically, lately...)