[cb321]

I agree that sheer package count is a weak metric especially for very hyped up "can I put it on my resume" prog.langs, and in the context of "maturity" (as opposed to "popularity"). I also agree that programmer attrition rate (or its complement retention rate) are a bit better.

While I cannot speak to Rust's packages, as part of testing a new Nim package manager against the published ecosystem, I happened to just a week or three ago be surveying the freshness of Nim's ecosystem. About 80% of those 1400 Nim packages have been updated in the past 2 years. By last git update, 50% have not changed since 2019/October and 30% have not had a commit since 2018/November. 50..80% fresh (with apologies to Rotten Tomatoes!) is much higher than I would have guessed naively. I am not sure even Python would score so highly. I realize these above numbers are but a start down a more real analytical road. Maybe someone could measure Rust in this way.

In terms of package quality, the one time I re-wrote something that existed in Rust in Nim, my Nim version ran like 10x faster than Rust. That was a couple years ago (https://github.com/c-blake/suggest if anyone cares) and is just one data point. I do think Rust unfairly enjoys a presumption of performance when almost any language has ways to make code run fast. Less ambitious or knowledgeable programmers can always make things slow, but they also seem biased against picking up Rust. So, there is also a sample selection bias, but this has probably all been said before.

[strokirk]

On the other hand, many many packages on https://pypi.org/ have not been updated in the last 5 years since they are essentially feature-complete. They don't need active development, the feature-set in the last published version still works.

[cb321]

It's a fair point that sometimes software is "just done". Combining the dependency graph with version freshness may yield even more informative retention/attrition metrics. { EDIT: as in "either updated in N months or a dependency of something which was". Of course, this can easily neglect reverse dependencies not in the package graph, but perfect can be the enemy of the good. :-) }