The “bug density” numbers (from the first study) here are highly suspect if you look at the underlying methodology. These are not accurate estimations. Furthermore, there are so many factors at work here that are not explicitly mentioned.
Someone else mentioned the experience level of the coders which is a major factor.
Another is the notion of “density”. It appears (since he didn’t really include any units) that the author of the study for the chart you reference didn’t even normalize with respect to LOC but only number of repositories. That’s crazy. Obviously, larger code bases will have more bugs and exactly explains why niche languages appear to do better.
Even if the numbers were normalized by LOC, it still assumes that that number of bugs scales linearly with LOC. I’m not sure that is the case. My experience is that the complexity of code scales with the “surface area” of the code which tends to increase more than linearly. As a result, it wouldn’t surprise me at all if larger projects had an inherently high bug density than smaller projects in the same language.
Another factor that is ignore…how long did it take to write this code? We might both implement the same functionality with two different languages and end up with the same number of bugs. If I can write it twice as fast, that is still a markedly better use of me (as a resource).
Finally, as somebody who has written lots of code in both dynamically typed and statically typed languages, I have a hard time swallowing any of this data. It doesn’t even qualify as a first-order approximation of relevant statistics. The correct methodology (and from what I saw neither study actually did this), would be to define a set of requirements for some non-trivial functionality and have different programmers implement those requirements using different languages. They should measure both the development time (that means writing code AND writing tests AND debugging) and number of bugs identified when the programmer considered the requirements met. Those would be useful numbers.