I do agree that the word “fast” in Phoenix advertisement is quite vague and should be perhaps replaced with “scalable”. The pitch I gave at my Phoenix talks is that with the stack of Erlang/Elixir/Phoenix, you can get on board quickly, move forward at a reasonable pace, write reliable, fault-tolerant systems, and be confident that the technology can help you go very far in the case your system becomes very popular and you need to scale it. That’s a bunch of wins on all accounts, and this is why I use and recommend Phoenix.
Raw speed is not Erlang’s forte (in fact sometimes it even sacrifices the speed for some other properties), so usually a sequential code will not be as fast as in many other popular languages. But the question for me isn’t who’s fastest, but rather is the tech fast enough? IME in the vast majority of the cases, Erlang is more than sufficient for my needs.
Doing various algorithmical and technical optimizations can usually take me very far. For example, looking at the rules of the “updates” task, I’m confused with some requirements and limitations. In real life, I’d try to optimize this task by performing a single update of all the target rows, say perhaps using UPDATE ... RETURNING of postgresql. I expect this would do wonders for the perf, since in a single trip to the DB I could change everything, and get all the data (and only that data) which I need.
Another option would be to try updating from multiple processes (currently it’s done sequentially).
This is not what’s advertised on the TE site. My understanding is that they think we should pick our framework based on their graphs, which is something I strongly disagree with given that the tests are synthetic, contrived, and poorly executed. You could just as well roll a dice, fire up a RNG, or consult a tarot expert to pick a framework 
