Yes, it has happened to me that type errors (both NPE and ClassCastExceptions) caused problems in production that should have been prevented by a better type system.
The last back-end system I built[1] had 3 failures in a year. First was a JVM misconfiguration (JVM neophytes) so we ran out of memory. Second was a temporary network outage that caused us to get behind our feed without the network bandwidth to catch up. Third was user interface code that wasn't tested.
Considering the system it replaced had more like 3 failures a day, the reliability was seen as "pretty good", so much that our relationship with ops was essentially we drop a jar, they tell us nothing happened.
TDD for the win. Not sure how/where a better type system would have helped.
A better type system is a complement to unit testing/TDD/other techniques. It simply allows you to focus on other, more meaningful kinds of tests.
You can think of a better static type system as unit tests that the compiler writes for you. When you think of it, automating things is what computers are all about. Of course this won't cover all cases, but neither will the tests you write by hand.
Anyway, you asked if that sort of errors happens. I answered it does.
edit: the problem with arguments like "well, I write software with few bugs and I don't need a better type system" is that it's essentially "just don't write buggy software" in disguise, which is a discredited line of thought in software engineering. People doing TDD (and every other technique/tool you can think of, including strong static type systems) still write buggy software. It follows that you should be using every available tool that can help minimize bugs and enforce correctness. Relative to the criticality of the software you write, of course -- sometimes you just don't care if the software has bugs.
> A better type system is a complement to unit testing/TDD/other techniques.
I agree that it could be such a complement. I haven't seen it in practice.
>It simply allows you to focus on other, more meaningful kinds of tests.
Again, I have seen this claim made many times, and it seems plausible at first, but I don't think it actually holds and have seen no real evidence for it. I don't think I've ever written a test for a specific type. I write tests for values. This automatically tests for types as a side effect, because values tend to have types. So these less meaningful tests that the type system would render unnecessary don't exist in the first place, and checking for the types separately adds no value (well, epsilon) in terms of safety. (Yes, I know it does a proof over all possible values, but this doesn't seem to make a difference AFAICT)
Note that TFA is about Swift, and many things that are actually benign in Objective-C will crash Swift...with no recourse as there is no exception handling. So I am not getting how being strict adds to safety.
> Anyway, you asked if that sort of errors happens.
Actually, I asked whether that sort of error happens to you (the person I was responding to). My answer would be: write better code, TDD allows you to that in such a fashion that you have no NPEs at 5am in production (without redundant tests for types). Of course, in Objective-C, nils get ignored when messaged, so you actually have to actively cause a NPE. Sadly, some of Apple's APIs do so. In fact, CFRelease() even throws a SIGTRAP.
