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!