Not too long ago, we were asked a great question by Eric Hu, on Twitter:
@omniref I'm curious what the most used Ruby standard libs (not gems) are. Your What's Relevant blog post comes so close. Any suggestions?— Eric Hu (@HuPineapple) June 27, 2014
We told Eric that we’d get back to him with that, because hey: we have a gigantic database of all of the public Ruby code, parsed and statically analyzed and indexed and generally big-data-scienced . So, easy, right? But the truth is, we had to think about it a bit. It’s not a trivial question.
So You Decide to Use Regular Expressions…
The problem with the Ruby standard library is that, unlike Bundler and Gemfiles, there’s no one definitive dependency specification. Sure, a file will require a library when it needs it, but that might only end up being a few places in a big pile of code. Or inversely, in some projects, you’ll see the same library required in every. single. file. So “files that have requirements” is a noisy metric, but the other extreme (“number of gems that use a library”, say) is bad too – because of the way we use Gems, a lot of code is implicitly dependent on stdlib code without really acknowledging it.
People also require code in the weirdest places. There’s just gobs of Ruby code out there where files are required in the middle of some deeply nested method (or worse yet: in metaprogramming code. have mercy, people.) So, of course, requirements are a total mess. Thus, we did what any self-respecting hacker does when faced with an annoyingly inexact problem: we used a regex. Specifically, this one: 
…now you have 577,617,200 problems. 
So what we did, you see, is that we took that monster, and we ran it against every last bit of Ruby code that we know about – all 578 million lines of it. And we broke it down by gems, gem versions and files: 
Raw Counts: Gems, Versions, Files, Lines
This is mainly just a state-of-the-state for us: we’ve processed about 80,000 gems, roughly 6x that number in terms of distinct versions, and a whole mess o’ files. Good to know. But how many of those require parts of the Ruby standard library?
Percentage of Gems/Files Requiring Any Part of the Ruby Stdlib
|Distinct gem versions||336,358||75%|
It looks like about 70-80% of gems have an explicit requirement for some part of the Ruby standard library. We wondered about this – is that number low? Our intuition says that a significant fraction (maybe a quarter) of all Gems are just learning exercises for the author, with little or no code, so it isn’t totally unexpected. Perhaps we’ll revisit this in a later post.
More interesting is the low percentage of files that have some requirement of the Ruby standard library. Up above we said that “files requiring a library” is a noisy metric, and this suggests that our intuition was correct; the data is sparse. But we’ll carry on with the analysis, and see what we get…
What’s the Opposite of “Data Science”? Data Superstition? That’s what we do here.
Enough dodging the question: what are the most popular Ruby standard libraries, already? There are over 100 different components in the Ruby stdlib, and while there’s some difference depending on whether you’re considering Gems, Files, etc., there are essentially ~30 popular libraries, and a long tail of unpopular ones:
So instead of listing all 100+ libraries, we’ll limit this post to the top 30 most popular. They are: 
|Most Included by Gem||Most Included by Version||Most Included by File|
(If this were a “data science” paper, this would be the discussion section)
It probably isn’t any surprise that rubygems is the #1 most included part of the stdlib, given that we’re analyzing a bunch of gems. But it’s comforting to see it there, since it inidicates that our data is in the right ballpark. More interesting, we see test_unit at the #2 position, which makes sense, given the Ruby community’s dedication to testing, right?
YAML and JSON are both very popular, so I’m afraid that we don’t have much ammunition to offer either side in that debate. Fileutils is where we get basic filesystem methods like FileUtils#cd and FileUtils#mkdir, so it’s probably reasonable that it gets included in a lot of files. And, of course, optparse is where we get the OptionParser class, which is necessary for nearly every program of any substance.
Ruby Trivia: there are currently about 580 million lines of code in all of the published Ruby Gems.
The first weird thing we noticed was the “popularity” of
tk in files, which, as far as we can tell,
isn’t that popular. But when you realize that there are a gazillion files in the
code for the Ruby Tk bindings, it starts to look more reasonable – anything that works with Tk at all
probably ends up requiring a lot of files.
Mostly, though, things come out as we expect, with perhaps a few surprises: date and time don’t make their first appearances until #17, which seems low, given how often programmers work with time (and given that socket is more popular than either). But then, net/http is also pretty popular, so maybe it just reflects the influence of Rails (and web programming in general) on Ruby’s popularity.
We won’t belabor this – but we feel like it’s worth pointing out the least popular pice of the Ruby standard library: the little-known (and humorously named) Rinda.
2) We didn’t use no stinkin’ online regex builder to make that, either. If it makes your eyes bleed, you need to back to data scientist school. All hail Steven Kleene. Respect.
4) Specifically, we took that regex and queried it against the file contents in our code database,
and did a
select distinct with a
group by clause on gem name, gem version or file path. So we’re counting the
number of gems, gem releases and files that reference each different component of the standard library. It takes
a while to run.