Will alternate languages take hold?
July 10th, 2008An often discussed approach to addressing multi-processing or multicore system architectures is that the programming languages utilized by most applications do not lend themselves to distributed and concurrent systems. Erlang typically comes up quickly in these discussions as an example of a language which has a set of language and runtime features intended to support concurrent execution.
You really owe it to yourself to watch the first few minutes of this video about Erlang from the creators. No… this is not a parody. It is just old.
There are a fair number of Erlang fans out there. Some compelling applications including Facebook’s chat system and Amazon’s Simple DB service have been created using Erlang. Sometime I ought to sit down and learn Erlang. I have my doubts, though. There just seems to be a limit to the adjustments developers will make to adopt a new technique or reach a desired improvement. Sure… Erlang might be the choice if you are doing an application that would be profoundly difficult without using Erlang. Would a developer chose Erlang for an application that looks moderately difficult but is just hard to get correct using standard languages like C/C++? I’m not so sure about that. Just human nature.
We can take some lessons from Erlang and use them as we consider architectures for multicore applications.
- There is a strong trend towards stateless application architectures. Shared state is the bugaboo in many of these concurrent systems. Some very large distributed systems are seen exchanging very popular system attributes (such as guaranteed simultaneous read consistency) in exchange for minimizing the state entanglements.
- Asynchronous loosely connected sub-systems. Structuring the application so that a human can still grok the functionality of the sub-system and can make progress. [ Before you start thinking RPC… here’s an interesting viewpoint. ]
So maybe Erlang-think ought to be part of your next concurrent multicore application?
