Same here. When I learned it, I expected to have more trouble than I did, and the syntax just sits nicely with me. Despite all the complaints about when you use which punctuation, the wart factor seemed a lot lower than all the bleating complainers prepped me for. Some warts you can't get away from (e.g. records, though you might use the parse transform du jour), but others you can (e.g. if? Who uses if? Just use case!).

Elixir looks nice, but for now I've got my eye on Joxa[1] instead.

Anyway, lots of people worry about learning this syntax or that syntax. In this particular case, they should worry less about learning syntax and more about learning OTP, because once you get past lightweight message-passing concurrency and immutability, OTP's where most of the power lies for building a robust system.

[1] http://joxa.org

I assure you that you are not. I find the Erlang syntax incredibly simple and elegant. Every solution seems to be just modifying some grand-unified pattern a bit to fit. But, I guess one mans Erlang is another mans APL.

I can sympathize, I found it's simplicity nice at first. But it quickly wears on you as your codebase grows and you have to refactor. You can find seasoned Erlangers complaining about it's peculiarity often, whether they'll admit it's a problem or not.

It has two major flaws:

* When you move code around, you have to pay a lot of attention to the "ant turd tokens": ; , and . or the lack of one in the right places. That is very annoying.

* It's very repetitive at times. Redundancy is great for servers, not so much for code you have to modify. Take this as an example:

https://github.com/erlang/otp/blob/master/lib/stdlib/src/fil...

It's got a lot of things repeated, and you have to play "spot the difference" to read the code and figure out what's going on. That's a fun game for my four year old, not so much when you're working. I like pattern matching, and it seems that with some tweaks, you could extract common bits of code and end up with something more succinct, so that you only write code that regards the actual differences between two code paths, rather than also having to write the same boilerplate over and over. I have been spoiled by Ruby's "don't repeat yourself" mentality.