Aye. Even ignoring per-project issues, there are so many compounding factors in these language shootouts as well - although I would be interested in seeing one

Aye. Even ignoring per-project issues, there are so many compounding factors in these language shootouts as well - although I would be interested in seeing one comparing, say, "comparable" JavaScript vs TypeScript projects. But it's hard to nail down all the compounding factors. Give me a static typing system that requires no effort on my part (e.g. is entirely inferred, negligible build time penalties, etc.) and has zero false positives (e.g. every type error reported by it is an actual bug to fix) and you'll have a very hard time convincing me this could be anything but a good thing, even on the most TDD driven of projects. It's basically a free lunch. The question then, is not if static typing conceptually is a good thing, but which static typing systems (if any) make satisfactory tradeoffs - and thus are more beneficial than not. With the rise of larger codebases and hard to exhaustively test things like multithreaded, multiprocess, and multinode code, I only find myself moving more and more towards static analysis (including static typing) on top of dynamic approaches (not just TDD, but various assertions, telemetry, logging, fuzzing, chaos monkeys, etc.)