About Elixir, I don't have very many complaints due to the fact that it is built over Erlang which means for day-to-day operations its solid. At the edge, perf

About Elixir, I don't have very many complaints due to the fact that it is built over Erlang which means for day-to-day operations its solid. At the edge, performance relies heavily on implementation, and the ErlangVM is great at dealing with high concurrency, and methods that do small pieces of work. If your implementation works against that, then the VM is going to work against you as well because it was designed with those assumptions in mind. Elixir however is a very new language. Coming from Python, the first things I noticed was: 1. There's no real consensus on if we should use exceptions or error return types. Support for return types is improving with the new with syntax, so perhaps that's what most people will use. The standard library uses both, and occasionally will just return nil on error. 2. The standard library is still evolving. For example Date/Time/Calendaring was all out of the STL until 1.3, and support is still currently anaemic comparative to Python. 3. Most OTP in the Erlang ecosystem are built in Erlang. Those built in Elixir are derived from some specific use case of some specific company. Language support for OTP constructs is improving though, and more generic forms are being built into the STL for Elixir 1.4, upcoming. With regards to Phoenix, its a well thought out, throughly implemented library.... but its not Django; and makes different philosophical choices. Short list: 1. no user system 2. no authentication or permissions 3. templates do not follow the engine/loader structure of Django 4. Plug is like Rack, not like Django middleware so whilst it is more powerful in some respects, it is unidirectional in control flow unlike Django where data flows up/down the chain of middleware. 5. Ecto is a pretty solid database layer, but its not integrated into Phoenix at all because #1/#2 do not exist, and Phoenix doesn't have a admin layer at all... so there's no real reason for the framework itself to tie itself to a single database layer. So you get into a situation that's akin to using SQLAlchemy with Django. Yes it works, no this library wasn't built for your framework.