This analysis seems a bit shallow and I'm not sure what point it's trying to prove. There are a lot of factors that aren't accounted for (as other commenters point out, project size is a major one), and a few others I can think of that would affect the metric used (apparently bugs/repo):

* Project management strategy for the repo/project.

* Commercial vs. non-commercial project.

* Ability and experience of the developers.

* Popularity of the project.

* Type of project (library, application, etc.)

I suspect all of these will correlate in a meaningful way with the language choice. Commercially produced or consumed projects may be more likely to have comprehensive bug reporting/tracking, and are more likely to be in a "mainstream" language, for instance.

Like Torvalds says, with enough eyeballs, all bugs are shallow. A corollary to that could be that without knowing how many eyeballs there are, and how well they can see, you don't really know how many bugs there are, either.

This analysis fails to take into account the popularity of a language. The repository of a library is likely to have more users if it's written in a popular language, and these users will probably report more bugs and feature requests.

Considering this I'm not surprised at all to see that Java, Python and C++ repositories have a higher "bug density" than Clojure, Go or Erlang ones.

What about Ruby?

I'm not saying that this metric measures language popularity, but that language popularity seems to have a big influence on it. I may be wrong, but that's what caught my eye when I read the article. There are plenty of other factors that aren't accounted for, some of which have been pointed out by other commenters.

What about JavaScript?

Does anyone know what unit is being used for the x axis on these charts?

Edit: Figured it out (total bugs / repo). Seems like controlling for overall project size is an important missing component of this analysis.

Agreed. I think (bugs/LOC) could even work.

That might be better, but it would still be misleading. "Denser" languages would have more bugs per line, but also fewer lines per program.

I've never used APL and wouldn't want to debug it, but its bug-to-line ratio could be much higher than Java and still come out ahead in practice.

APL is considered by many a write-only language.

> Seems like controlling for overall project size is an important missing component of this analysis.

That would bias the numbers against more concise languages.

This analysis seems as though it could be misleading. Couldn't the number of bugs reported vs. the actual number of bugs that exist in the code differ significantly?

It's impossible to find the truth by a single observational study with ten data points and tons of unaccounted variables.

Aside from project size, the problem domains of libraries are likely to vary hugely between languages. With statically typed languages being biased towards either systems programming or more algorithmically complex tasks.

The proportion of Haskell libraries for tasks like string padding is probably lower than the proportion of ruby or js libraries, for example.

static languages and dynamic languages simply have different ways to injure yourself.