Fact is, they do spend a lot of time coding, but most of the code they write is either boilerplate, countermeasures to the language shortcomings, or tests to keep the language from biting you.
At some point (and if the codebase is not that good to begin with) one might conclude that the language is being hostile. A bit excessive maybe, but understandable.
This happens with every language, especially when maintaining 10 year old projects. Even a 10 year old project written by middle-of-the-bell-curve programmers in Haskell would be inducing the same amount of ire. "Who writes types this way?" "Did they even think about refactoring the existing types when bolting this other crap on?"
It's the maintenance that's driving this guy nuts, not the language itself. Haskel just happens to be his side project, which will, of course, look cleaner. I felt the exact same way when moving from Perl to Python.
> It’s hard to reason about code when it does something entirely different depending on what code has executed in the runtime before it.
> What we really need are more explicit guarantees on every line of code that we write [...] than what Ruby can provide
Maintenance has a cost on any language, but in some cases you also have to make up for the lack of guarantees the platform gives you. Tooling, as you said, can help, but substantial effort is required to develop and mantain, say, a (production-grade) static type checker. You can't just tell $random_ruby_dev to "help improve tooling" if there is no tooling to begin with.
Perl is also user hostile. So is haskell. Many languages are not, and people don’t typically build and maintain software in them for a reason—it’s expensive and slow compared to, say, java. What’s your point?
At some point (and if the codebase is not that good to begin with) one might conclude that the language is being hostile. A bit excessive maybe, but understandable.