I’ve worked through the Elixir getting started guide as the first step in my goal to build something in Elixir. So far, there are lots of things I like and a lot of things I find kind of strange.
The fact that Elixir is up front about the performance profiles of lists and tuples is encouraging. Understanding when certain operations will be slow helps us make good decisions about design.
The string support seems amazingly robust. The guide claims that Elixir passes every test contained in The String Type is Broken. Being able to avoid dealing with terrible string implementations is a huge benefit and, in the long run, probably worth putting up with a lot of other issues.
Parallelism is a primary concern, which is just as appealing here as it is in Go. Combined with immutability of Elixir variables, it provides an environment where you can reduce garbage collection based issues more easily.
I really like the pipe operator. Here’s a normal line of code:
Enum.sum(Enum.filter(Enum.map(1..100_000, &(&1 * 3)), odd?))
Here’s that same line of code using the pipe operator instead:
1..100_000 |> Stream.map(&(&1 * 3)) |> Stream.filter(odd?) |> Enum.sum
With some exceptions (like the pipe operator), the syntax is not very friendly when compared to languages like Ruby or Python. I get that some of this is probably the result of most of my experience being in imperative languages, but I just don’t find Elixir intuitive or easy to read.
This might seem like a little thing, but for most applications it is the most important thing. An employee’s time is often far more expensive than another server or ten, so languages that are harder to read have a higher “total cost of ownership” than ones where the intent is easily understood.
In terms of being “better” than Ruby or Rails, it still seems better in ways that Rails doesn’t concern itself with. There is a lot of interesting stuff in Elixir, though, and I’m looking forward to taking a swing at a practical project as soon as I make it through the Mix and OTP tutorials.