I still consider myself a beginner in Elixir land, but it’s quickly becoming my favorite coding language.
I was trying to solve a data aggregation problem whilst generating a CSV file for a shipping partner, and I was having an incredibly frustrating time. I spent more than an hour banging my head into a wall just trying to get a data structure to conform to the customer’s needs.
I took a walk and reminded myself of my principle in the title: If I’m fighting Elixir, I’m probably using the wrong approach.
What turned out to be an hours-long frustration was solved in 4 minutes with a comprehension. Simple, daresay elegant, and, most importantly, obvious in hindsight.
In other languages, there are many terrible ways to solve most problems, and I can end up writing code that seems utterly bonkers to me down the road (looking at you, Javascript 
). Elixir usually shows me what ends up being the best path forward.
What do you think? Am I completely off base? Or does this seem to match your experience?
4 Likes
Well, it is not that similar approach is not possible in other languages (it must be possible in any Turing Complete language by Church-Turing Hypothesis), it is just that in Elixir good solution is often the obvious one. To be 100% correct - I have similar feeling in most functional programming languages, especially untyped ones (like Lisps and Erlang). Elixir is very Lisp-ish language so you can apply Greenspun’s tenth rule there as well - that is probably why you feel that way.
2 Likes
100%. In China, they say “Don’t push the river.” In Elixir, more than any other language I’ve worked with, when code is sloppy or confusing, it is generally wrong: it seems to really incentivize clean and elegant code.
6 Likes
I am Chinese and I don’t even know what are you referring to, but I totally agree. I think the value proposition of a functional language is that you spend twice as long, writing code half the size, implement the same functionality as compare to using a OO language. It seems like a productivity loss but you more than make up the loss by having dramatically less bugs in the code.
5 Likes
That’s a good way to put it.
