Not just Elixir, but because of it I would say the runtime and otp, to think that a bunch of tech were already there and nobody saw it is at least intriguing and now I barely need a bunch of infrastructure libraries, proccess is there, cache is there, kv storage is there even a database, and nodes without all of the complexity.
joaoevangelista
jordiee
otp(supervisor trees/ genservers) is what blew my mind about the language. Completely changed how I wrote my code. Much stuff I was using other services for like Redis or sqs I do all in code now and its great!
5
minhajuddin
Pattern matching in Elixir is amazing! I’ve never before seen such powerful stuff in other languages.
6
ranyefet
I have to say pattern matching and guards changed the way I write code and I miss them in every other language that I use (mainly JS)
3
PragTob
Definitely pattern matching. It truly changed the way I think about code and it’s the kne thing I wish I had in every other programming language going forward.
Second to that railway oriented programming with the with expression
5
tmbb
It’s interesting that pattern matching in Elixir is such a primitive notion (just like in erlang, of course). Actually, Elixir could have implemented pattern matching with macros. I have implemented a special form of “pattern matching” myself in my megadef library. It shows how easy it would have been to implement other forms of pattern matching inside elixir
EDIT: There are very good reasons not to do what I’ve done in my package by default, of course. It’s good for some situatuons but a disaster in others.
5
AstonJ
A picture paints a thousand words - here’s the code, reproduced with the kind permission of @ulissesalmeida 
def ascending([]), do: []
def ascending([a]), do: [a]
def ascending(list) do
half_size = div(Enum.count(list), 2)
{list_a, list_b} = Enum.split(list, half_size)
merge(
ascending(list_a),
ascending(list_b)
)
end
defp merge([], list_b), do: list_b
defp merge(list_a, []), do: list_a
defp merge([head_a | tail_a], list_b = [head_b | _]) when head_a <= head_b do
[head_a | merge(tail_a, list_b)]
end
defp merge(list_a = [head_a | _], [head_b | tail_b]) when head_a > head_b do
[head_b | merge(list_a, tail_b)]
end
So it was actually a recursive function inside a recursive function while also calling the outer recursive function 
ascending → merge → ascending 
5
dwahyudi
In terms of syntax, nothing in Elixir really blows my mind, no… seriously, everything is expected. Just functions and more functions and pipe of functions and more functions, some with syntax, some comprehensions, yeah nothing really fancy. No pointers, no instance variable (that can be changed on other methods/functions). Just modules of pure functions. Protocol and behaviour are a bit harder to think about though.
Phoenix is a bit more surprising, because it has some itty bitty magic on the MVC thing. Other than that, nothing really surprises me.
It is pretty different when I code in Javascript, like everyday, something surprises me out of nowhere.
“How does it work like that?” 
In terms of performance and especially concurrency, Elixir really blows my mind.
7
tmbb
My favorite: iolists have some very interesting performance characteristics: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2-io-lists-in-phoenix/
5
Shrike
I have to say the let it crash mentality, before meeting Elixir I always thought I should avoid crashes make sure that nothing crashes and deal with different crashes all the time.
After meeting Elixir threads finally clicked threads can crash we deal with it and are not afraid of it.
That basically changed my whole view point to threads, they are our friends not our enemy, at least when you know how to use them.
Immutability was great too, but let it crash mentality is the best thing that happened to my coding and made 10 times better in my job.
I think that since I met this forum I only had one instance of singleton problem and that was because ruby duplicate sometimes do weird things.
3