The Ruby Stdlib is a Ghetto

Much of Ruby’s standard library (the set of classes shipped with the Ruby VM itself) is old and crufty. For laughs, go look at the code for some of the classes that you’ve never used. Chances are it’s from 2000-2003 and doesn’t even look like idiomatic Ruby. I’m wondering what classes should be removed from the standard library or deprecated so that higher quality replacements can take their place.

The canonical example is Ruby’s net/http library. Its performance and API are just terrible. (Side note: how do you know if an API is terrible? If you have to consult the docs even after having used the API for the past 5 years.) But because it’s in the standard library, most people use it as the base for higher-level API abstractions (e.g. httparty, rest-client).

So looking at Ruby’s core RDoc, my suggested list for removal (where removal means move to a rubygem):

  • Net::*
  • DRb
  • REXML
  • RSS
  • Rinda
  • WEBrick
  • XML

Any others I missed? Will Ruby 1.9.3 or 2.0 get a good spring cleaning or will we have to live with these classes forever?

34 thoughts on “The Ruby Stdlib is a Ghetto”

  1. I’ve advocated moving the stdlib core to gems on ruby-core, after a brief discussion with Matz at RubyConf, he definitely didn’t say no (or yes, that is :) ) for Ruby 2.0.

    I’d love to see every stdlib package as a gem, and then that default set comes with the base install of Ruby. If you’re up for prototyping this, let me know or hop in #rubygems on FreeNode.

  2. I like your suggestions. Those parts of the Standard Library would be well suited to getting extracted into external gems. The only one I might be hesitant about is the Net::* group since that is some useful functionality to have easy access to out of the box. I think a case could also be made for keeping some kind of XML parsing capability in place, especially if you are leaving YAML and CSV capabilities in the library.

    WEBrick, RSS and DRb certainly seem like pieces that ought to be extracted. The only other thought I would have is that this is a major enough change that it should be put off to 2.0, rather than 1.9.3, just so you maintain backwards compatibility between minor version releases.

  3. I’d love to see many of those replaced with some gems, for example rexml swapped with nokogiriI’d love to see many of those replaced with some gems, for example rexml swapped with nokogiri

  4. I don’t know if all of these can be removed (if they are leaves in a dependency graph):
    Base64
    CGI
    CSV
    Digest
    GDBM
    GetoptLong
    Iconv
    JSON
    Jacobian
    Kconv
    LUSolve
    NKF
    OpenSSL::*
    RDoc::*
    Readline
    TSort::*
    URI::*
    Zlib::*

    imo they are too specific. I like clean/small standard libs :)

  5. What I’d suggest is looking at each lib and seeing when it was last updated, filtering out cosmetic changes like updating a copyright year or whitespace changes for example.

    I’d bet that libs with the least amount of churn, are also the least maintained, and the least likely to be used. I think they should be the first to go.

    While too much churn in sections of code is usually a sign of something wrong, I think too little is also a bad sign. It means either the code is absolutely perfect in it’s public interface, documentation and tests, or (more likely in this case) it’s something no one uses, so no one reports bugs, submits patches or cares enough to update it.

  6. There’s some rather important points from packages on the ruby-core mailinglist about the technical issues to do with this. Most notably many of these libraries have specific branches in the ruby code base that pertain to specific ruby versions and have not been maintained in a backward compatible way. RubyGems at present does not have support to treat 1.8 vs 1.9 as a “platform” and so there’s no clean route to providing alternates.

    There’s also a whole bunch of issues with the current rubycore approach to embedding gems. If we want to move more libs into gems then they need to be shipped as real gems and installed as real gems, not this halfway house that causes instability (try gem install rake on a head build, for example – you get an explosion in Gem.bin_path – this is because the hack that’s used is incomplete and doesn’t conform to the gems api).

    The problem, contrary to some reports, is not that people are not suggesting this. The problem is that no one is coming up with solutions to the actual problems that are introduced by trying to do this. It’s only a step forward if people solve the problems.

    Sorry to put a downer on an idea that I otherwise wholeheartedly agree with.

  7. Also, net-http-persistent clearly shows that net/http isn’t actually /that/ slow. I don’t see another *complete* http library that’s really comparable in ruby at the moment. Note please that I say complete – this is important.

    No, I don’t think it’s ideal, but partial implementations are not http libraries, they’re hacks that supporta handful of use cases. Common use cases or not, they’re not replacements.

  8. Like raggi said above, this is quite a bit less cut-and-dried than it might look at first glance. Those who examine it in more detail tend to get quiet fairly quickly.

    Please prove me wrong, reader, we’ll all thank you for it.

  9. YAML, based on Syck, needs to be taken out back and shot. It’s so full of bugs and nobody’s patching it since _why is on permanent vacation. Considering this is a core component for many apps, this is a sad state of affairs.

  10. I always thought it was weird having those libraries, but kind of cool at the same time. I’ve used net::http many many many times, I don’t think its so bad. When I’m developing a small embedded system on ruby, its nice to have net::http, yaml and RSS support built in. DRb and WEBrick I would also keep around, but I agree with removing the rest into gems.

  11. Now that sounds like a really great idea to leave stdlib without any HTTP client. It will sure make Ruby code more portable.

    Same for XML and DRb. I fully agree that all these APIs are pesky, but they certainly should stay in stdlib, although in a much better incarnation. Most importantly, Ruby’s biggest problem is lack of standardization. Ruby programmer literally live under Japanese rule. Compare that to Java’s JCP, or Python’s PEP. With concepts like these, Ruby would be able to move on, and fix it’s stdlib issues.

  12. I believe these libraries need decoupling from the stdlib. I don’t see this realistically happening, however. The guys at Phusion found many optimizations in MRI ruby in REE ruby, and yet not too many have been reincorporated back into MRI. There seems to be apathy is this, which is why the core team could just not care about removing these libraries from stdlib.

  13. grosser wrote:
    “kill stdlib, everything that needs to be required should be a gem.”

    Yes, because managing dependencies can be so much fun.

  14. i like removing all stdlib, allowing them to be installed by gems.

    yet i see some issue with packaging (by distros) and dependencies — especially during updates — that make me believe it is better to give some options wrt what “level” of stdlib you install..

    - a bare minimum by “default”
    - a collection of “core” libs
    - and a collection of “more” libs

    all libs admitted to default/core/more are fully tested before a release, assuring there are no issues within the release.

    distro’s can then provide ruby-corelibs and ruby-morelibs alongside “ruby” itself.

    next would be to make a test service that tests your software automatically for the upcoming ruby (and core/more stdlibs) release :)

  15. This type of change could only happen in Ruby 2.0 due to compatibility issues. I don’t know if it is really on Matz and the core team’s radar but I agree it needs to be done. There are too many cases of bad libraries in core (Rexml and Date/DateTime) which have great alternatives (Nokogiri and Homerun) but can’t get inclusion due to core resistance over compatibility concerns.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>