The point is that a dynamic language will in some cases enable code that is simpler and more readable (and hence probably more reliable) because sometimes the simplest code is code that wouldn’t type check. Even if statically typed languages are more readable on average, this fact invalidates your claim that statically typed languages are strictly better in terms of reliability. This can only be true if you artificially restrict attention to the subset of programs in the dynamic language that could have been statically typed.

By the way, could you tone down the rhetoric a notch?

You’re flipping the claim.

The original post says that claims about static typing improving reliability are “not falsifiable” and are “just vibes and feels.” That is the claim I’m responding to. And it’s simply wrong, because the claim being made is not empirical in the first place.

Holding everything else constant, static typing eliminates a class of runtime failures by construction. That is a statement about language semantics, not about teams, readability, or whether people write good code. It does not require falsification or evidence any more than “bounds checking prevents out-of-bounds reads” does.

When you argue that dynamic languages sometimes allow simpler code that may be more reliable in practice, you’ve changed the topic. That’s a claim about human factors and development process, not about whether static typing removes runtime failure modes. It may be true, but it’s orthogonal.

So to be clear:

- The original claim (“this is unfalsifiable, just vibes”) is false.

- Static typing removes a class of runtime errors by definition.

- Whether that tradeoff is worth it in real projects is a separate question.

Once you separate those, there’s nothing absolutist here. The only rhetoric is pretending a semantic property is an empirical mystery.

You can't "hold everything else constant" because the set of programs that satisfy whatever type system is a proper subset of the set of valid programs.

That’s a very long and indirect jump to make.

The claim that admitting a larger set of programs improves reliability goes through several speculative steps: that the extra programs are correct, that they are simpler, that simplicity leads to fewer mistakes, and that those mistakes would not have been caught elsewhere. None of that follows from the language semantics. It’s a human-factor argument layered on top of assumptions.

By contrast, static typing removing a class of runtime failures is immediate and unconditional. Programs that would fail at runtime with type errors simply cannot execute. No assumptions about developer skill, code style, review quality, or time pressure are needed.

Even in practice, this is why dynamic languages tend to reintroduce types via linters, contracts, or optional typing systems. The extra expressiveness doesn’t translate into higher reliability; it increases the error surface and then has to be constrained again.

So the expressiveness argument doesn’t invalidate the claim. It changes the topic. One side is a direct property of the language. The other is a speculative, multi-step causal story about human behavior. That’s why the original claim is neither unfalsifiable nor “just vibes.”

So regardless of speculative human factors, the claim stands: holding the language semantics constant, static typing strictly reduces the set of possible runtime failures, and therefore strictly increases reliability in the only direct, non-contingent sense available.