People in my line of work (writing distributed, network applications) seem to be afraid of Erlang. Several reasons, I think:
Developers
Something new to learn, and thus they feel that they’re at a disadvantage, or won’t be able to contribute.
Managers
Worried that they won’t be able to find developers to work on the code base once the original authors leave, and fear that any new technology is just as bad as the last few “hacks” they graciously allowed to invade the architecture (except Java, which is somehow always the right thing).
The strange thing is, I see people all over the place who want to work with Erlang (or Python or Ruby or Scheme or Lisp or Smalltalk), not so much because Erlang is a cool language, but because it solves so many of the problems they have to deal with day in and day out. And it’s a cool language.
The whole thing strikes me as a destructive, self-fulfilling prophecy. We won’t invest in the small amount of time it takes to learn the language because we don’t see that there are potential employees out there to be hired if we need them. And there aren’t any potential employees because no one will let anyone use Erlang for production projects.
A Catch-22, to be sure.
What distresses me is that, deep down, such decisions aren’t rational. They’re based on fear. Fear of change, and fear that one’s employees might be necessary to one’s success, rather than being discardable, fungible assets. One could claim that choosing Erlang in itself is emotional, and I’d tend to agree, but it’s a positive emotion: pleasure at being able to solve problems more easily, pleasure learning something new, pleasure at opening up the possible range of solutions for any given problem. If one makes a decision on emotional grounds, these are the right emotions.
What also distresses me is that I don’t believe hiring managers know anything at all about who they need to hire, and the skills they need, and thus fall back on the notion that expertise in a set of platform tools means anything at all. (A man who can wield a hammer with the best of them may or may not be good at building cabinets.)
Right now, when I see job positions asking for candidates well-versed in Java, J2EE, Spring, Hibernate, Inversion-of-Control, and so on, I see a shop in which very little gets done over a long period of time, a process-bound, over hierarchicalized, overly large team: the mythical man month incarnate. I see a recipe for failure.
Like the lumbering empires of old, the appearance of strength and stability hides a vast and empty core.