This is a pretty good take on Tim Bray vs Erlang. However, I’d like to focus on something said at the end:

The fact is, all languages optimize for particular problem domains and I don’t think that a universal programming language exists that would perform well on all tasks. Bray rapidly found out that Erlang isn’t optimized for doing line-oriented I/O and it’s regex library sucks. So what? While those problems could be eliminated from Erlang, the fact that Ericsson has deployed large telecom gear without having to fix those issues means that Erlang is ideally suited to its original programming domain.

The problem is that learning new languages is difficult for many people. They’re not going to bother starting from 0 with a new language if what they’ve got is only 10/20% worse than the other guys. For companies, developing expertise (and trying to maintain it) in lots of languages is probably less productive than picking a few (Google only has four: Java, Python, Javascript and C++, and they’re not exactly lacking in brainpower or cash). This is why “the right tool for the right job” works for things like saws and hammers, but not for complicated, idiomatic things like programming languages.

Therefore, it’s important that languages that aim to be widely used do lots of things pretty well, and try to avoid doing anything really badly. This is something I’ve always admired about Python, even if I don’t use it anymore. It’s a language that you can do a very wide variety of tasks with, and you can be sure there’s probably some code out there already, and that Python will be ok for your task, even if it’s not the best thing. Performance is a weak point compared to compiled languages, but even there, get the libraries right and things aren’t so bad.

In any case, my point isn’t to bash Erlang (which I like), or put Python on a pillar (I prefer Ruby and Tcl), but to say that a widely used programming language doesn’t need to be the best at everything, but it should aim to make people comfortable using it, safe in the knowledge that they can probably do most things ok if needs be. That’s a far better situation than being able to do one thing realy well, and perform poorly at many other tasks, forcing its users to look elsewhere for solutions to those tasks.

Personally, I think that for concurrency, Erlang is in a bit of a race right now – they’re pretty far ahead in terms of concurrency (and also fault tolerance, but fewer people care about that), but behind in other areas (less library code). Other languages don’t have as good a tools for concurrency, which isn’t an easy problem. So, what will happen first – Erlang catches up elsewhere, other languages get “good enough” concurrency solutions, or a new language (like Scala) comes along and takes the lead?