What matters more than the language is the kind of work you’re doing day-to-day, which depends on libraries, internal code, and the problem space. You can do things properly in dynamic languages. It just takes a little bit more discipline.

Common Lisp’s GETHASH returns two values, with the second value being T if the value was found.

You nailed it. The type system acts as a language-generated basic unit testing suite, with the added benefit of being faster (it is done by the compiler rather than a testing farm and supports incremental testing which further reduces the time between creating and detecting the bug).

And it’s fairly easy to teach yourself how to leverage type annotations for further testing, by adding type constraints that match domain constraints (“an overdrawn account cannot be charged”) that are not immediately obvious from the code itself. I’d say 25% of an average unit test suite can be replaced by type inference, and an additional 50% can be replaced by appropriate design of types and surgical annotation strikes.

foo true true = true;
foo false _ = false;
foo _ false = false;

H-M typing will assign a type of bool -> bool -> bool. But this is only a small subset of what foo can actually accept: for example, (foo 32 false) is false and so is (foo false “yack”), whereas (foo 32 “yack”) is an error. So the typing is pessimistic; it prevents errors at run time at the expense of being overly restrictive.

Success typing gives this function the type any -> any -> bool, which is optimistic and reflects the way dynamically typed languages actually work. Dialyzer has found lots of errors of this type in large, well-aged code bases: it has the advantages that it can be run offline rather than intertwingled with the compiler, and it never generates a false positive. What’s more, you can add Javadoc-style comments specifying the intended type of a function (Dialyzer already knows about Erlang’s built-in functions), and if any uses are inconsistent with these, Dialyzer will tell you so.

Existing type systems have a lot of annoyances and problems: no question about that. And then there is the functor/type-class debate: tye classes are a lot nicer for simple cases, while functors are more general and powerful (to get full functor power out of Haskell, you need the type system extensions).

I have seen errors where, for example, one might have two identical (under the hood) types, such as “float” and “length”, and get a compilation error because of the type mismatch, but that’s generally held to be a desired behavior. I don’t think it’s what you’re talking about.