Brilliant post by CM on the differences between Rails and Phoenix:
We’ve also seen an improvement in code clarity. We’re converting our notifications system from Java to Elixir. The Java version used an Actor system and weighed in at around 10,000 lines of code. The new Elixir system has shrunk this to around 1000 lines. The Elixir based system is also faster and more consistent than the Java one and runs on half the number of servers.
https://engineering.pinterest.com/blog/introducing-new-open-source-tools-elixir-community
I installed elixir last night. I don’t know when I’ll have time for it, but first hurdle overcome.
4 Likes
I know this feeling…working thru the Programming Elixir book right now after taking a hiatus for a couple of months…some code katas.
1 Like
Anyone know the reasoning behind why we can’t do this in Elixir:
"hello" + "world"
=> "helloworld"
5 + 5
=> 10
[1,2] + [3,4,5]
=> [1, 2, 3, 4, 5]
But instead we have to do this:
"hello" <> "world"
=> "helloworld"
5 + 5
=> 10
[1,2] ++ [3,4,5]
=> [1, 2, 3, 4, 5]
Is it because maybe the latter is how it’s done in Erlang?
Or is it because they are actually doing different things (concatenation vs addition).
Just curious 
I would image it was to circumvent the problem with different types e.g.:
"hello" + 2
If you can’t have overloaded operators, you know the type of c in
c = a + b
to always be a Number, where, if you could use + for both Numbers and Strings you wouldn’t know the type of c before evaluating the expression.
You might also run into a problem with precedence. What is the result of:
"hello" + 10 + 20
1 Like
Yeah I guess… but the compiler would complain and let you know. I think the way Ruby handles it just seems a little more intuitive - you think it will work and it does (and it saves you have to remember three different things).
I am guessing this is more to do with it being what Erlang does… will have to have a look now or the curiosity will kill me lol 
Edit: Hmm well maybe not this is Erlang:
string:concat(A, B)
or
A ++ B
http://erlang.org/pipermail/erlang-questions/2012-May/066537.html
I do think, that it simply was a decission of design.
- One could get confused when the result of an addition is not a number. Also one needs to question how the system should handle additions of different types. If I am able to add two number, and I am able to add two strings, what does happen when I add a string and a number or vice versa?
- One is used to some arithmetic laws:
a + b == b + a, this does not hold if you use+for cancatenating lists or strings. - Since there is no compile time typechecking in Elixir, you could have a function
def inc(x), do: x + 1, which could receive a string at runtime. Having an overloaded+would give you unexpected results which might get hard to debug. Not having it overloaded gives you a nice stack trace -
<>for cancatenating strings and binaries can also be used in pattern matching, which might be hard with an overloaded + (it would not only DO different things with different data, it would even get completely different meaning depending on the side of an equal sign its used on)
Thats what comes to my mind.
1 Like
For those of you interested in Elixir - the Elixir Forum has gone live and we are also running a competition to give away a copy of Programming Elixir 1.2 every month until the end of 2016! Check out the competition here:
1 Like
Hey Elixir folks, I wrote a Ruby gem to bring your pipe operator to Ruby. Instead of |> you need to type ᐅ as the method call. The gem is called elixirize. Enjoy!
3 Likes
I’ve updated one of my projects to use the new elixirize gem! Here’s the diff
And an excerpt example:
Before
view = ERB.new(IO.read(File.expand_path('../view/main_menu.erb', __dir__)))
After
view = File.expand_path('../view/main_menu.erb', __dir__).
ᐅ( IO.method :read ).
ᐅ ERB.method :new
1 Like