The Ruby comparison is kind of shallow (and not that helpful) - I would describe it as Erlang with a “Ruby-esque” coat of paint; and “coat of paint” really doesn’t do justice to the Elixir meta-programming (macro) facilities. In the end I found Elixir to be “less strange” than Ruby.
Pattern matching is part and parcel with recursion and higher order functions, the practical FP backbone of Elixir/Erlang. PE introduces these ideas much more gradually, while EIA crams them all into Chapter 3 (so it’s a great focused recap after PE’s “Part 1 - Conventional Programming”; n.b. “Sequential Programming” would have been a better heading).
With Erlang R18:
erts/compiler: enhanced support for maps. Big maps new uses a HAMT (Hash Array Mapped Trie) representation internally which makes them more efficient. There is now also support for variables as map keys.
The Erlangelist: Elixir 1.2 and Elixir in Action
For Elixir in Action, this means that all the code that’s using HashDict should be changed to use maps. Most notably, the Todo.List abstraction should internally use maps to maintain the entries field. You can see the changes in this commit.
i.e. whenever you see HashDict just replace it with a map %{} and functions from Map.
While EIA may not introduce you to the syntactical niceties of Elixir 1.2, 1.3, or 1.4 it’s code and solution approach is absolutely solid because it’s founded in mature and established Erlang practice.
Watch ElixirDaze 2017- Solid Ground by Saša Jurić.
Also Elixir is an extension of the Erlang ecosystem so you may be interested in this: Erlang and Deep Learning by Garrett Smith
[quote]Wonder to what extend should I know how to use elixir before I can touch Phoenix, as I am more keen to build web app (SPA) and API 
[/quote]
You really benefit if you have your head wrapped around “OTP Applications” first. The currently favoured Phoenix design approach is:
- Put your (arbitrarily complex) business logic in an OTP application.
- Then use Phoenix to expose that functionality to the Web either via HTTP requests or web sockets, for web pages or SPAs.
i.e. don’t entangle your business logic with the web backend (FYI: Patterns: Backends For Frontends).
In fact many Phoenix resources will focus on using EEx templates for web pages. Phoenix can support SPAs but the SPA is largely a concern separate from Phoenix (and Elixir). Some (FP-style) frontend technologies are Elm, PureScript (Building a Graphical IDE in Elm/Purescript), BuckleScript and of course ElixirScript.
