Ruby Stdlib is a Ghetto, Pt. 2

Eric Hodel disagreed with my recent point. I didn’t present much of an argument because I didn’t think there was much disagreement with my point. Let me elaborate.

1) It’s full of unnecessary libraries that should be separately distributed

The Ruby community, at least in the US, has proven to be very open to change, see Rails 1, 2 and 3 for example. Sometimes you have to break compatibility to advance the state of the art. Continuing to bundle inferior implementations means that we have this compatibility albatross around our neck while stronger third-party libraries don’t pop to the top of the ecosystem. Some random dude said it better than me. Some other dude agreed, REXML in this case should be unbundled.

I was proposing unbundling DRb and Tk not because their codebase sucks but simply because they aren’t used by the vast majority of the Ruby community. treetop and shoes are very useful libraries also but they don’t belong in stdlib either.

I’m not proposing we do this in the next 1.9.2 patch, but for 2.0, sure. Now that rubygems is in core (thanks Eric!), I think we should be aggressive in unbundling everything that can be unbundled.

2) It’s (still) too hard to contribute

The Net::HTTP docs haven’t been touched AFAICT in 5 years. They’re full of broken English and rudimentary examples. I hear people complain about it all the time, why hasn’t anyone fixed it? Maybe everyone is lazy or maybe the contribution process remains too steep for most.

Net::HTTP had performance issues in the 1.8.6 era, sounds they have been fixed. The API is still poor and poorly documented IMO. Just about every HTTP library has a better API IMO, e.g. Typhoeus, httparty and rest-client. As someone else pointed out, Ruby really does need an http API in core though, if not just for Rubygems to use.

I would love to see ruby-core treat git as a first class citizen and allow pull requests and git email patches against http://github.com/ruby/ruby. If this is the case today, please let me know. I will be the first to submit a pull request for better net/http docs.

12 thoughts on “Ruby Stdlib is a Ghetto, Pt. 2”

  1. RubyGems isn’t in core, what’s in core is something that’s /almost/ RubyGems, the difference makes me frequently want to break things.

    All of those libraries you mentioned with “better APIs” than net/http have apis design for very specific use cases of http. That’s not a generic http use case. Sure, adding some sugar to net/http might be nice, but lets please not pretend rails and rest are the only things out there.

    Also, typheous docs clearly lie about net/https performance. After fixing that, net/http does the same bench in under 600ms too. You also talk about idioms, well, just trying to fix that libs benchmark has led to a big cleanup of bad practices. My point is, *anything* can be ripped on.

    Only patches count.

    https://github.com/raggi/typhoeus/commit/c683b7d2f0ba3fd01f962b9eb3e0a0307bd0f0f6

  2. You do not present much of an argument here either, Mike. Have you read the ruby-core discussions regarding gem unbundling? (I think most recently in the nokogiri inclusion thread.)

    Documentation commits are not particularly onerous. You correct the doc, extract a patch and file a ticket.

  3. iirc, at rubyconf Matz said that they are planning to make github their primary source control solution once he learns git. The plan is for this to go into effect by the time ruby 2 is released at christmas time (of whichever year, as he put it)

  4. The HTTP API isn’t “poor”, and I challenge you to find a suitably complete alternative. As or the docs – well, you know what to do.

    On some of the others I am in somewhat more agreement. REXML is a mess, and Tk probably doesn’t belong in core. But honestly, I’m not sure who is being hurt by any of these dependencies.

  5. Matz said at RubyConf X that they were working on transitioning to Git (I think he even said Github), but they have a lot of things that depend on their existing svn infrastructure. For an idea of what it takes to do such a migration, take a look at the story the PostgreSQL people posted a while back.

  6. Although I’m not arguing for or against the removal of Net::HTTP your argument doesn’t make a lot of sense. You say it hasn’t been touched in 5 years and yet they fixed performance for it post-1.8.6 which was released 3 years ago. It’s either been improved in the last 3 years or the performance gains were because of Ruby.

    Also ignoring the bad comments and examples you cannot judge the quality of a project based on the last commit date; there are thousands of projects which have not been updated for a years at a time and yet remain perfect for their use. HTTP is not a spec which radically changes every year – so what would you want Net::HTTP changed to support?

  7. I posted some of my objections to the net/http library on Avdi’s blog.

    Stuart, I said “The Net::HTTP docs” haven’t been touched in 5 years. What does that have to do with performance? I’m judging the quality of the docs based on commit date because the docs have had bugs (poor English) in them for 5 years without getting fixed.

  8. Interesting that you pick net/http. I submitted improved documentation in 2005. I added more examples, including a full example with retrying and error reporting. I thought they were accepted, but it looks like they were either ignored or reverted, so I’m re-submitting them.

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>