Aug 28, 2007

More Erlanging

One of my favorite reads from my infosec days was teenage mutant ninja hero coders, a blog by computer security expert Maximillian Dornseif. Dornseif usually says smart things and you should probably be reading him.

Lately, his subject matter has turned to more general programming topics and distributed systems. Dornseif wrote about Erlang's unsubstantiated reliability claims recently, and follows up on that today.

Dornseif's point:

"Erlang is an interesting language. OTP is great engineering. Erlang has considerable momentum compared to other languages with unusual concepts. There is no need use 99.9999999% which ring[s] so hollow."
That's pretty easy to agree with.

I've seen two conflicting schools towards the end of figuring out where Erlang fits in the current programming language landscape. One is the ever-popular "right tool for the right job" school, which posits that you build your distributed components in something like Erlang and other components in languages with more mature, easy-to-use libraries. While this is admirable and pragmatic, the downside is that you then have to couple your tools with language bridges or interoperable formats like XML, JSON, or a message queuing standard. The coupling components can be brittle or eat up processing time with expensive parsing and conversion.

The opposing school is well-represented by, again, Russ Beattie:
" [...] I just don't like working with multiple languages at the same time. I much prefer to have one language in my toolbox that I try to use for as much as possible, so that I can avoid time-sapping context changes, re-use code, and become more proficient with each line of code I write whether its on the desktop, in the browser or on the server."
I've known lots of developers for whom a solution isn't a solution if it isn't available in their language of choice. Context-switching can, indeed, be brutal.

At the moment, I'm not ready to take a side. I've always been a multi-linguist, and I see ups and downs to both sides. It's interesting, is all.

1 comments:

Bob Ippolito said...

Erlang itself isn't "nine 9s" reliable, but the strategy that its libraries encourage is very reliable. Have at least two of everything (including machines), lots of redundancy and transparency, and fail fast. It's certainly possible to write very fault tolerant systems given sufficient time and expertise, and you get a lot of the expertise for free via OTP and the docs.

As far as error propagation goes Erlang does you a favor because the pattern matching is bound to fail if something goes haywire, which will kill the process so that functionality will be diverted to a process/node/etc. that works. It's almost like contract based programming a la Eiffel.

Nothing that Erlang does couldn't be applied with the same success to any other platform, it just makes it a lot easier and in many cases more efficient. I certainly considered writing Erlang-like libraries for Python, but it made more sense for us to just use Erlang.