During dev, I had a server live for users to play with. The data structures were in flux, there was zero traditional data input protection. My users were domain experts, no tech background and would type in all sorts of odd inputs as there was no training or documentation on how to use the webapp. But I never once had data corruption issues and never once did the server crash. I was able to run this "test" server with no admin or headaches while I was doing dev.
The reasons are due to a few characteristics of erlang:
1 - you write concrete pattern matching, not abstract object containers. So a controller or model function would spec out a clear data structure that was expected as input. Anything else failed right at the point where the data didn't fit the patterns and guards.
2 - each request is handled by an isolated erlang process that fails gracefully and doesn't effect the rest of the system. So my early testers would get error dumps from the server for bad data inputs but they never corrupted the data or crashed things. I was able to take these error messages from test users to see how they were using the system incorrectly.
3 - Single assignment and functional programming were a big win in terms of writing once, testing once (not writing separate test code), and knowing that that piece of code was solid and I could move on.
The app was very responsive. All requests were ajax and this system felt like the server was running on the same box as the web browser. When we had errors, the erlang error message almost always showed the crash at exactly the point in the code that needed attention.
These characteristics speak to the power of the dev process, not scalability which is what you normally hear about erlang.