Approaching Erlang

Erlang is the tech news more and more these days as a possible tool for designing software to run on multiple core machines.  I’m very interested in servers and high-end server software so I have been following the news to see if Erlang will take off like other languages.  I must admit that I’m not the type to jump onto new languages at a whim.  I’m more intersted in building systems than I am in fancy frameworks or nifty syntax or what not.  Though I’ve considered devoting some time to messing with Eiffel or Ada or Smalltalk or Python, I don’t really have a reason to devote my free (which I prefer to spend on foreign language study) time to them.  C++ and Perl do everything I have ever needed, and I”m already very familiar with the Standard Template Library, POSIX API, Win32 API, and other standard interfaces.  Ultimately when I try a new language, the reason I give up on it is that it takes a lot of time to master new APIs and frameworks.  No matter how many times I tried to do something with Python, it was faster to simply hack it out in C++ even if the code size was much larger.

Erlang does offer something that C++ cannot offer me though: a unique concurrency model without shared memory.  Writing multi-threaded software in C++ is always an exercise in syntax rules, debugging and humility.  Win32 Threads and PThreads are C APIs that force one to battle with static object behavior in your OOP applications.  You might remark that Python and many other languages have threads, why Erlang?  For me, it is all about doing away with shared memory and simplifying the system design.  What’s more, Joe Armstrong, the author of the language, has provided lots of data on the performance of Erlang.  I am also impressed that Ericsson and Nortel, two big cmpanies in the telecom industry I work in, employ Erlang in network telecom equipment that is used in massive telecom systems.  Telecom software is some of the most robust software operating in the wild!

I picked up Joe Armstrong’s text, the only text on Erlang, at this time, and I’ve made it to chapter eight when the concurrency discussion begins and you dive into Erlang’s message passing constructs.  I have to say that so far I am struggling with the language though.  I understand the concepts, it is just hard to apply them to real software.  The idea that you cannot have variables is really messing with my brain.  Once you assign a value to a variable it remains that way forever–everything is “const”.  To communicate with another process, send a message.  It is going to take some time to really get the ideas burnt into my brain.

Perhaps another issue is that the basic syntax is so different from the C-language syntax that is common amongst all of the programming languages I use:  C++, Perl, Obj-C, Assembler, and Verilog.  (Well I guess Assembler is different, but it ties right in their with C with the memory layout.)  I really need to dive in and solve a problem that I’ve solved in C++ so that I can see the bigger picture.  All of the talk about “funs” and pattern-matching and what not is not helping.  The section on dealing with binary data is mind blowing in its own way.  Bit vectors can be 9 bits in length!  I don’t think I’ve ever really considered anything but multiples of eight.  I just need to be patient and keep reading until I get to TCP sockets.

It has certainly been a very enlightening way to look at writing software thus far.  It is interesting to see a totally different approach to what I have grown accustomed to with OOP and imperative programming styles.  More to come in the future, I hope!


6 thoughts on “Approaching Erlang

  1. i think that the fundamental reason for the impedance mismatch is (most likely) due to functional nature of the language. if it is any help, i would (humbly) suggest to read SICP along with joe’s book (and ofcourse work through the problem sets as well !)

    i am currently at ch 3 (of sicp), but using erlang (along with scheme). it’s not too shabby.

  2. If you haven’t done much functional programming before, it might be a nice refresher to pick up a book on scheme. The scheme syntax and constructs are much more simple than erlang, and I think lend themselves to picking up the nature of functional programming more readily than erlang does. So a quick jaunt through little schemers over the weekend, might leave you in the same spot that a weeks worth of studying erlang would.

  3. Thank you both for your advice. Yes I agree with you, I think it is the functional programming style that is the wrench in my cogs. I’m just not accustomed to the pattern matching, the ability to create your own controls structures, non-mutable variables and so on. I see that SCIP is available online so I will take a look at it and see if I can wrap my head around it.

    I have to say that I do like this approach and I can see how it leads to power in the long run. You aren’t limited by the language, rather you’re free to create with it whatever you need. I think that once I get the hang of it I will probably enjoy it. Maybe it will encourage me to look into C++0x and Boost attemps at introducing some functional style to the language!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s