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.
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.