It is logically flawed to say that because one lightweight language system has been running very reliably, that static typing doesn't help with reliability.If you read through Joe Armstrong's thesis, he describes several large and small systems built using Erlang. More about the software itself and other conference reports are at the Erlang open source site.
If the Erlang examples are not enough, let's consider other languages.
How about Smalltalk? Read on James Robertson's blog how he's able to debug and update live servers. Read Jay Almarode's articles on Gemstone Smalltalk (index to PDF's), how it provides multiple users a distributed, persistent, versioned dynamic system that's kept applications running in finance, insurance, medical, manufacturing, etc. Read about JP Morgan's use of Smalltalk in their financial management system which won a 2004 Computerworld award.
Maybe you'd like to know about Lisp and how it's used by Orbitz for travel planning. There are many similar successes with Lisp.
The list goes on.
I want dynamic languages to succeed in this scenario too (I'm a python fan), but I don't see any evidence, other than partisan flag waving, which demonstrates the superiority of either methodology in creating reliable systems.There is sufficient evidence that dynamic languages succeed in creating reliable systems. I have not seen a reasonably supported hypothesis for static languages in these situations. That is, I have seen claims that they will catch more errors, or catch them sooner, or reduce testing, but I have never seen substantial evidence in support of these claims.
If you have any such evidence, please let me know. My own experience includes building significant systems in several agile and rigid languages over twenty-four years. Based on that experience I would only choose a dynamic, agile language.
Do you have any actual evidence as to why dynamic languages are better for creating very reliable systems than are statically-typed languages, or just that one anecdote?Read about the systems above. These languages are *agile* in that they support flexibility and evolution of dynamic systems. Static type checking tends to be *rigid* which, in the small without a test-driven approach, provides the illusion of security. As systems get larger, statically specified information become even less important and even more of a hindrance to change.
Our initial intuition is that reliable systems must be specified up front, and since static type information is easy to specify up front, then this must be the foundation of reliable systems. Almost the opposite is the case. We do need up front specifications, but they should be simple expressions of small parts of the ultimate system. Those specifications should be in the form of tests and dynamic (and concurrent) models, and simple solutions that fail fast.
Read about the systems above. The wisdom is not entirely intuitive relative to many of today's popular programming languages and tools. But the history of computing is inevitably moving in this direction.