One reason I chose Erlang
Meanwhile, back at Ericsson, some Erlang-based products that were already in progress when the "ban" went into effect came to market, including the AXD 301, an ATM switch with 99.9999999 percent reliability (9 nines, or 31 ms. downtime a year!), which has captured 11% of the world market. The AXD 301 system includes 1.7 million lines of Erlang: This isn't just some academic language.
I really should write more about Erlang (as I promised), but I've been busy actually writing CouchDb in it. Anyway, the above fact about the extreme reliability of a 1.7 LOC switch was one big reason I chose Erlang for CouchDb. I did it sort of on faith, not sure why I should use this language, only that it claimed to address problems that I couldn't figure out how to solve with regular software tools. And it seemed to walk the walk with real shipping products.
So I had high hopes about Erlang, and I must say I haven't been disappointed. Honestly, I was expecting something different. I'm not sure what I was expecting, but what I found surprised me big time, the Erlang OTP platform has completely changed the way I view reliable software construction. One thing I've found surprising was it's just as easy to create bugs in Erlang code as it is in other languages, it does not have a silver bullet to eliminate software defects. But its reliability doesn't come from being so much better about creating bug free code, but how well it tolerates bugs and faults.
In properly designed Erlang software, when a component has a problem, -- it hit an unexpected condition, runs out of memory, times-out, etc -- the component is restarted. If the problem continues, then the parent can be restarted. If necessary, the system can shut down the faulty component permanently, or continue restarting components until the entire application is restarted, essentially a fresh restart.
Basically it has built into it a notion that shit will happen, so let's not allow small problems to wreck our whole application. It goes a long long way towards addressing otherwise intractable problems like memory leaks, memory fragmentation, deadlocks and infinite recursion. Kill first, ask questions later might as well be the Erlang motto. And why not? You just respawn what you kill. And while it may sound hard to write software this way, it's actually far easier than you think, because there is very little error handling code cluttering up everything.
This incremental restart strategy is not possible in languages with mutable data and shared state threading models (such as Java, C# and just about every other mainstream programming language).
Posted June 13, 2006 12:50 AM
Comments
Cool. The fail-fast implementations I've seen in other languages were not pretty but the strategy works. I'm waiting for your detailed articles. What about that process communication stuff? Tell us about that.
Dan Sickles, June 13, 2006 2:08 AM
And while it may sound hard to write software this way, it's actually far easier than you think, because there is very little error handling code cluttering up everything.
There's something this touches on that I haven't yet figured out a good phrase or metaphor for: There are hard, scary problems in computer software, like programming massively concurrent programs like Erlang programs tend to become very naturally.
The natural temptation is to skirt around the problem, try to avoid the domain, and just sort of hack around and get by. Hence, the dominant threading model of today with shared memory being the primary paradigm, and thread-level memory being the exception, and all the fun locking and race conditions and such that ensue. And you feel like you've accomplished something.
But sometimes, if you gird up your loins, bravely attack the problem head-on, take no prisoners, no holds barred, and let the problem domain guide you to another locally-maximal solution, you can end up in a local maximum much higher than the first one.
I've been playing with Erlang myself lately, and I get the feeling that that is where Erlang is; by embracing multithreadedness instead of cowering from it, and following it where it goes instead of trying to drive it, it ends up with an exceptionally powerful approach to software. I regret to say I don't think Erlang is going to ride its way up to the top in its present form (short form: too foreign for most people to cotton too due to its functional heritage, but I think that's the programmer's problem, not Erlang's), but I am fairly certain that in 10 years, something very like Erlang is going to be one of the dominant languages of the day because of how we'll all be running 128-core machines on our laptops and how naturally Erlang extends into that environment. (In fact I'm almost not certain how this statement could be wrong...)
Another example of this, IMHO, is "breaking backwards compatibility"... you can either cower from it, like the Microsoft camp does, and forever live with ugly kludges and lose big on every major Microsoft upgrade, or you suck it up, take the pain, and just deal with it over time like the Open Source community does. Long-term, I think the Open Source community will win on this point, as they continue to develop environments and programs that only carry around the valuable bits of backwards-compatibility that somebody was willing to fight for, instead of carrying it all around at all costs in perpetuity.
There are other examples too, but I drone on....
Jeremy Bowers, June 13, 2006 8:25 PM
re: Jeremy on open source and breaking backwards compatibility...
As a developer, it's easier to annoy your customers (by breaking backwards compatibilty) when they aren't paying money.
Anonymous, July 7, 2006 3:03 AM