How cool is Erlang?
January 18, 2012 § 1 Comment
A few years ago it seemed like everyone in the Ruby community was checking out Erlang, I guess they thought it was the next big thing, or cooler than Ruby or something. Anyway that seemed to pass as everyone found Scala and recently it seems Node is the place to be (unless you want to run fibonacci sequences). Actually if you’re super on it, you’re probably writing CoffeeScript, ignoring the fact that its just JavaScript.
Anyway, that all said, around that time, like many rubyists I bought “Programming Erlang: Software for a Concurrent World”, started reading it then realised it was kinda hard, and well I had other things to do. Since then I have actually read it, in fact a number of times, along with various other Erlang books and have decided that it is, well, pretty cool. Here are a few things that I’ve really liked and have found useful even when not writing Erlang.
Functional
This might sound obvious because Erlang is a functional language, but having mainly used OO based languages I found this refreshing. Functional languages have some pretty nice features. I particularly like the avoidance of state, mutable data and the lack of side effects. A good example of this is that a function can only be influenced by its given arguments, meaning that the same function with the same arguments will always return the same result.
Actors
Everyone knows Erlang is all about roflscale, sorry, concurrency and it does this through the actor model. Scala actually does its concurrency pretty similar and there even Ruby libs adding actor like support (Rubinius also reportedly has an actor api). The core idea here is that actors can pass messages between each other, this is the only way they can communicate as they share no state.
Single assignment
Often people think that Erlang has no variables, thats not strictly true. It does, but you can only assign them once. Various other languages have this construct (Scala does, although it allows ‘normal’ variables too) and whilst it initially feels restrictive it can make debugging way easier and also allow us to paralize programs with greater ease.
Pattern matching
Erlang uses pattern matching *a lot*, when you assign a variable you are actually pattern matching, you can use pattern matching in functions and also in case statements and the like. This often results in clear, readable code.
OTP
Erlang and OTP often seem to be used interchangeably, OTP stands for Open Telecom Platform and is actually a collection of libraries to do common tasks. What I like about this is that many of the hard problems (fault tolerance, code swapping, etc) are gained for ‘free’ using OTP meaning you can concentrate on the
domain specific problem at hand.
I’m still learning to love Erlang, but the above are probably my favorite takeaway points, that I’ve found useful outside of Erlang. If I had one gripe about Erlang being hard, I think it would be that the docs and examples (or lack of) are, I feel, lacking. This is what I’ve found the hardest, although this may be down to inexperience or not knowing where to look.
I’m still a relative beginner, but my understanding is helped as Erlang is much more mathmatical (evaluating functions) rather than traditional (imperative) programming. I first heard about Erlang on my studies of multi-core processing:
http://www.economist.com/node/18750706
then I learnt a bit more:
http://learnyousomeerlang.com/