In general, type checkers almost never catch any errors that wouldn't have been found extremely quickly in a strongly typed dynamic language.
Having worked in a large codebase to fix type errors in an evolving language, this is not true. There are plenty of errors.
What is true is that the errors you catch are most often benign and not obvious, user-visible bugs, for one reason or another. (If they were obvious, they would have been fixed sooner.) The code might be abandoned or rarely executed, or it's never called with that argument. Something like that.
Occasionally you do find a serious error, though.
Re:Elm 0.19 Broke Us
by star-techate on Saturday August 25, 2018 @07:39PM
(#17843206)
"Extremely quickly" -- if you can always take all sides of every branch in control flow. And you'll find only the same errors -- if you restrict the types you define to those supported by the dynamic language. If you don't restrict yourself, however, you can start catching classes of error at compile-time that in a dynamic language you could only look for by writing your own runtime checks.
And runtime checks aren't free - they cost CPU, they can have their own bugs, and they can be tedious to write. "In general", rather than even try to be as careful in a dynamic language as you could be with an advanced type system, you'll just settle for not being careful.
If you’re doing any real work on the web, you’re going to have to use external libraries and code and such. You’re not going to have time to recreate an entire mapping framework in Elm or whatever and the minute you need to commingle in such a way you loose a major benefit of such system.
Also “no runtime exceptions” does not mean the application isn’t broken, does not absolve your developers from real testing and QA their changes.
Also it says a lot when someone wants to call their framework a kernel and patterns their behavior off you know who.