Erlang Musings

Completely bogged down buy our 2.0 release push at work, generally not a lot of time to blog these days. That combined with the Twitter micro-blog phenomena and I'm neglecting this blog. Sorry for the two people who read this :)

I did want to capture some thoughts on the recent discussion on the Erlang mailing list around Damien Katz's post about Erlang.

To preface my comments, I've been using a decent bit of Erlang over the past few weeks and have been learning the language for several months now. My current endeavors are in the distributed load-testing arena (Tsung didn't meet my needs). I'm by no means an expert and have nowhere near the experience of Damien or the members of the Erlang mailing list, but I'm beginning to feel like I'm not a total n00b.

Initial thoughts on Damien's post:

• I've also found refactoring a bit difficult. Over time, defining an entirely different function to elicit a slight behavior change generally results in some parameter munging then a call to an existing function. Problem is, in development, the behavior of that existing function often changes thereby affecting all the calling functions.
• I was also intrigued by the response to Damien's post on the Erlang mailing list where I lurk but rarely post. Some highlights:

• "sometimes giving a whining child a lollipop is a rational thing to do." - Richard O'Keefe clarifies this comment in subsequent posts, but the condescending attitude towards other languages continues to discredit him IMO. I generally get this sense from the Erlang community - "we know functional and you don't, so don't bother us with your critique of our superior language." Not sure why early adopters of most languages feel a need to succumb to Napoleonic urges and lash out at successful platforms. Java bashing is so very original these days...

• Robert Raschke also jumps on the Java-bashing bandwagon but with less valuable critique other than that he doesn't want to write Java in Erlang - not sure who asked him to do so.

• As usual, Ulf comes through with solid, valuable feedback.

• My experience has been similar to NAR's and I related to his comments for the life of the thread. In particular, defining dozens of one-line functions has made flow control difficult to follow in some circumstances. Probably my lack of understanding towards the language idioms but building on Damien's points, there aren't consistent examples of those idioms so it's easy to lose your way. I stand by my claim that Wide Finder proved this for file I/O in Erlang. It shouldn't take a committee to help you write good file handling code.

• I found Alpár Jüttner's comment interesting: "I think, the major obstacle for newcomers is not the syntax, but the immutable data structures". As a newcomer, this was not an issue for me at all. In fact, having spent more time than I care to remember worrying about dirty reads of shared memory, this is a welcome addition to my programming routine. Rather, I struggled with multi-byte strings (referring people to ejabberd is not sufficient documentation for an entire language), function proliferation, syntax ( =:= ), and most importantly lack of libraries.

• Robert Raschke's clarifications as line endings was a huge help here.

• The fact that POST'ing a form with http:request remains an enigma (eh, where are my param encoding functions?) really makes me feel like the language is a DSL for networking gear. Yes, Erlang is more expressive and concise than Java, but that doesn't mean much to me when I can write a Scala function to make an HTTP POST in four lines of code and have it run screamingly fast where as the same Erlang takes two dozen lines (and based on the documentation is questionably not process safe). I have the sense that the Erlang community would happily provide me with 10 different functions to solve the parameter encoding issue, but that misses the point - I don't have to worry about such things in most other languages I work with.
  

In summary, I actually agree with most of Damien's original post. Having written a good bit of C/C++/Java/Python/Ruby, his observations are generally representative of how I feel approaching Erlang from that perspective.

Like Damien, I have a lot of issues with Erlang. I kind of hate Erlang. I hate it in the sense that I wish I had a better, more familiar solution to programming with actors. At the same time, it's immensely powerful and expressive. Every time I use it, I think "wow, I love functional programming" and "actors are so important, it will be amazing when the programming public realizes why we all need to do this".

At the same time, the syntactical and idiomatic issues I have with Erlang constantly nag me. I'm sure these will ease over time, but I have yet to reach a point where I've stopped looking/hoping for alternatives. Given some of the attitude displayed on the mailing list, I won't really have a lot of community loyalty if given a comparable option.