[mjoin]

Unpopular opinion given all the craze around Elixir these days. I find the syntax extremely verbose and hard to read compared to e.g. Python. I was told great things about it by engineers I really respect. But each time I start reading Elixir code bases to get a good look at what an actual Elixir project looks like, I find the code hard to read and understand. Is it just me?

[abadpoli]

I was a python main before I started using elixir and I had similar thoughts, but after becoming more familiar with it, I actually think elixir is far less verbose than python.

They’re different enough languages that it’s really difficult to just open up an elixir codebase and try to read it. Elixir, like ruby, has a lot of syntactic sugar that just won’t make sense if you approach it with a Python mindset. Elixir is also functional, which can be a pretty big mind bender.

It’s really a language that you need to start from the basics and go through the tutorials to learn the basic syntax, operators, etc and write your own small programs. If you’re like me, you’ll just end up discouraged if you expect to be able to learn Elixir just by reading existing code.

[rubyn00bie]

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.

[mjoin]

Thanks a lot for sharing your perspective. This convinces me to give it a proper try!

[scop]

I think there are two things going on:

1. The syntax is significantly different than what one may be used to. Fair enough. 2. The paradigm itself is different and thus requires you to learn way of structuring your code in some pretty fundamental ways. This is a much bigger deal than one may initially give it credit for. For example, pattern matching. The mere possibility of defining multiple versions of the same functions based on the number and kind of arguments completely changes how one writes functions.

Instead of:

function hello(x) {

if (x == 2) {

// do x

} else {

// do y

}

}

We can write:

def hello(2) do

# do x

end

def hello(_) do

# do y

end

This was very disruptive to my brain at first as I was not used to reading code in this manner. My brain said "find function, read definition" but it had to learn "find function with proper arity and arguments, read definition". It's hard to put into words, but this made understanding Elixir code feel more difficult at first. However, once I did sink my teeth in , start to maneuver around code bases, and write my own modules it is hard for me to "unsee it" and go back to anything else. I love it! I think the most mind-blowing moment was when I started to pull back the covers in Phoenix and discovered that the framework wasn't some magical black box of FancilyNamedProviders but was just a collection of functions that I could actually read my way through quite simply. I never had to stop and say "wait what did that FacadeOfGoodness do again" but just traced simple functions.

[ch4s3]

Having worked a bit in Ruby, Python, and Elixir I think a lot of the difficulty comes from the minor differences. There aren't any objects or classes so the structure is naturally different and there is a tendency to have a lot of small functions so it must be read differently. If you're seeing tons of deeply nested Enum.map type calls, that's probably just bad code.

[mikhmha]

I think its worth spending more time in it. I've been working on an MMO in Elixir and I find myself coming back to rework/expand earlier subsystems and expecting to dread understanding WTF is going on but that has not been the case at all! Regardless of what knowledge I had of Elixir at the time I wrote the module - I can quickly pick up the chain of thought I had when I first wrote it. The code usually boils down to a combination of atoms (symbols), pattern matching on atoms, tuples, return values, and some sort of enumeration using Enum.map or Enum.reduce to produce an output. There's no other fancy tricks beyond that. And regardless if the data changes from list of tuples, to a map, or a set, the Enumeration logic doesn't change.

[fouc]

Maybe you forgot how long it took to learn to read & understand the code of the programming languages you're familiar with. Elixir is so different from languages you might know there's a learning curve.

[klibertp]

> Is it just me?

No, it's the same for everyone: unfamiliar things seem "wrong" until you internalize them.

Try working in Elixir for half a year - you'll see that the syntax you now find verbose is that way for a bunch of reasons, and you'll find that you have no problems at all reading Elixir code, including in big projects.

The problem is that confronting the unfamiliar doesn't feel nice for most people and that you can't really speed up the process. On the flip side, though, half a year of weekends is not that long of a time or significant an investment. Especially since you'll get quite a few generally helpful skills out of it (working with actors, for example).

[lytedev]

I felt the same way at first coming mostly from JS. I think it's different enough that you need it to become familiar before it feels as comfortable.

That said, I don't think it's as easy to read as Python, but the perceived verbosity and reading difficulty definitely goes down with familiarity.

[natrys]

Tbh, I find well written Elixir to be easier to read than Python. But that's mostly down to functional vs imperative which is subjective/cultural. The same code using higher order functions and pipes that feels much simpler to me would likely be unpalatable to most Go programmer I know, and maybe a lot of Python programmers too (tbf, I can't stand the vast majority of Go code I have seen either).

Part of the verbosity is because Elixir is kind of a simple language (if you disregard the OTP stuff) and doesn't have a lot of sugar - ultimately it's just functions. Whatever else sugar is there is to nudge you towards a somewhat opinionated aesthete. In this specific regard, it's not unlike Go or Smalltalk (even if in any other way they are very different otherwise). I think the stylistic variance in how different people write Elixir is pretty low compared to how people write Perl/PHP/Ruby/Python, which is probably why reading difficulty quickly goes down with some familiarity.

Other part of verbosity is probably because culturally Elixir is kind of explicit. For example Phoenix is very convention heavy, but it's still low on framework magic. It's cool that Elixir (and Julia) has macros and that's good for library and framework authors to contain verbosity without sacrificing much of the explicitness. But as an application developer I very rarely need to reach for them either? Perhaps that's due to simplicity of language and synergy between data structure and standard library.

Though based on usage there are probably some areas where I would have preferred more sugar. For example, you just end up doing a lot of deconstructing/pattern-matching Maps. Every time I do `%{var1: var1, var2: var2} = map` I wonder if it would really be bad to have `{var1, var2} = map` like Javascript? It's not a very big deal though.

Also not to be a naysayer, there is a chance that the good feeling people have about Elixir is because they basically use it in the problem domain where the language and the runtime (and Actor Model) is an exceptionally good fit for. I mean web and network stuff is already large part of what people do, so that's not much of a con? Nevertheless would I pick Elixir for my next GUI or CLI program? I doubt it.

[lytedev]

I like your take here quite a bit. Thank you for sharing!

[ikety]

You'd probably love gleam. Elixir ecosystem dwarfs it at this point, but the syntax and design choices are just phenomenal.

[mtndew4brkfst]

Elixir ecosystem is in turn dwarfed by dozens of other languages. It is still extremely niche in the big scheme of things. I can't personally recommend pursuing Gleam for any serious work on those grounds, but my risk aversion and sensitivity to hiring pools is on the very conservative end.