> Still worth a read though, and makes a strong case for functional, statically-typed languages.

The thing is, it really doesn't. There are too many inexplicable results. Typescript does significantly worse than Javascript, for example. There's also no real good explanation why the results for Ruby and Python are diametrically opposite, basically (the languages are more alike than different). And Clojure has the best result of them all.

I suspect that there are simply too many confounding variables that are not accounted for (such as the typical application domains for those languages, average programmer skill, or complexity of the problems being targeted by these projects).

Yes, I think after reading to the end I agree with your summary.

I still think there is value in using languages that eliminate entire classes of bugs though, for example using a language that has automatic memory management is a no-brainer except for certain specific domains where you need to do memory management yourself. Likewise with static typing: it eliminates type bugs. There have definitely been times for me recently when working with a dynamic language like JavaScript and there's been a bug in our code base that would not have happened had we been using TypeScript. Some of these bugs also had significant business impacts.

There is of course a trade off, typed languages can be more challenging to develop with: I've had a number of fights with the Scala compiler. Typically it's libraries rather than the base language, but it still costs time I wouldn't have spent if using a dynamic language. Also, the Scala compiler itself is very slow, to the point where the XKCD comic about "code's compiling" has been true. On modern Macbook Pros, this shouldn't be a thing anymore, but it still is :)

> I still think there is value in using languages that eliminate entire classes of bugs though, for example using a language that has automatic memory management is a no-brainer except for certain specific domains where you need to do memory management yourself. Likewise with static typing: it eliminates type bugs.

In practice, it's not so simple. It probably holds for garbage collection (assuming GC is suitable for your application domain), but static type systems come with costs. There's plenty of evidence (via studies) that type annotations are really valuable as documentation, but the argument for bug prevention is less clear. Most bugs that are caught by static type systems are also generally prevented by other approaches (because they're basically clerical errors that you hit fast even during basic testing). Conversely, there are plenty of real bugs that aren't caught by type systems (or only by type systems that are essentially full-fledged specification languages, or by putting lots of work into types).

While there's a huge difference between having a validation strategy for your code and not having a validation strategy at all (or winging it), it's much more difficult to assess the relative value of different validation strategies, especially once you take costs into account.

> A lot of the conclusions are along these lines: languages with explicit type conversion have less [type conversion] errors. Well, of course...

Well, of course, indeed... There is a bogus argument here, and it is not in that part of the study which is being ridiculed. Modifying the statement you are arguing against is often an indication that something isn't quite right.

Of course, what matters here is the overall error rate, possibly weighted for severity (though trying to do that is itself problematic), on comparable tasks. In a rational world, anything that can eliminate an important class of error, without making corresponding increases elsewhere, would be regarded as a success.