|
I’ve been writing Elixir professionally for ~10 years at this point. I find it to be extremely easy to read, but that’s because side effects by and large don’t exist, and when they do they are very obvious. Ive written quite a lot of Ruby, JS, Swift, Obj-C, and Java during my career and Elixir is miles ahead of those for readability. With that said, I do think because the syntax being familiar for Pythonistas and Rubyists that there’s an assumption it works like those languages and runtimes. It does not. It’s a functional language, in a purely functional VM, and that causes a lot of grief to newcomers. There are many assumptions folks bring with them that don’t hold. I think you have to take a step back when you come to a functional language with an OOP background otherwise it’ll be painful. I’d encourage you to just write it for a while and avoid things like GenServers. Get a feel for just writing functional (pun?) code. Id also suggest to avoid reading code by people new to Elixir as it’s often weird, or irregular, because they lack the experience to write things idiomatically; relying too much on OOP principles. As an example, in Ruby you strive to write functions less than six lines (in general)— in Elixir this can be an antipattern. Because breaking up the function will unnecessarily abstract and muddle what’s going on. That in large part is driven by the fact there are no side effects; I can see everything that is going on. Whereas with Ruby side effects and meta programming are prolific, making the code extremely dense. Writing a method that’s 20-30 lines in Ruby almost guarantees it’s violating the single responsibility principle. The one thing that did trip me up when starting elixir, that I now love, was shadowing variables. It makes things look like they’re being mutated but they absolutely are not. It’s just reusing the same name, not the same value. |