> Basically everything that makes the source code less readable than the original: uppercased variables, the minuses that prefix the module and export statement

> Basically everything that makes the source code less readable than the original: uppercased variables, the minuses that prefix the module and export statements, Capitalized variables stand out from lower cased functions. I find that makes it easier to read than having everything lowercase. It's enforced so all the code has to follow that convention. Semicolon at the end of a function clause indicates there is another function clause following it, that is a useful affordance when navigating code. > The minuses that prefix the module and export statements Well in natural language you use dashes to create an itemized list. Would # be better like in include statements in C/C++? Maybe the alternative is to introduce some "defun / fun / def / function" keyword to define functions and another keyword "directives"? But that is less ergonomic, I really like how function definitions don't have to start with an extra keyword and they are just function names starting on the left side of the page. > the wierd =:= operator. Yap that is a weird one. = is used for pattern matching so reusing it for equality / equivalence testing might be ambiguous. > Basically everything that makes the source code less readable than the original: The original has "remainder of _ divided by _". That looks ok in a small example but repeating that phrase throughout the program many times is probably not the best idea. Overall, after reading large code bases of Erlang, Python, C++, C#, and Java. I would put Erlang right behind Python and readability and how ergonomic it is. The most important thing about it is it is small and self-consistent. Contrast that with a "modern" language like Javascript which looks "familiar" but is not very consistent and full of gotchas (see the famous wat video on that).