This post originated from an RSS feed registered with Ruby Buzz by Eric Hodel. Original Post: The Ruby Stdlib is not a Ghetto Feed Title: Segment7 Feed URL: http://blog.segment7.net/articles.rss Feed Description: Posts about and around Ruby, MetaRuby, ruby2c, ZenTest and work at The Robot Co-op. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Eric Hodel Latest Posts From Segment7

I have read Mike Perham's post on ruby's stdlib and strongly disagree.

Mike presents only the thinest of arguments, that his list of libraries are "old and crufty". While many of the libraries are old, few are crufty and he does not present any list of libraries that should replace them and I find this very troublesome.

It's very easy to say, "this sucks", it's only slightly less easy to say "this sucks and here is why" and it's hard to say "this sucks, here is why and I'm going to do something about it".

Mike picks out Net::HTTP as his prime example saying Its performance and API are just terrible but does not back his performance claims with any benchmarks and does not back up his API claims with any examples. The rest of his libraries fall under "old and crufty" but I've heavily used many of the libraries listed and don't share those experiences.

Net::HTTP Performance

I have benchmarked Net::HTTP against the curb gem and it is far from slow. When I performed these benchmarks I found that curb was terribly broken. Curb didn't use persistent connections (and as a consequence maintained the open connection until GC) and didn't support manual closing of connections as a workaround to the first issue. This made curb's performance atrociously bad.

These issues were rapidly fixed and under two weeks later curb 0.7.3 fixed the performance issues. Compared to curb 0.7.3, Net::HTTP is about 2.4 times slower than curb. I find this damn good when comparing a pure-ruby library to a C extension.

Of course, if you're serious about performance you need to use persistent connections (which is the main reason curb has historically been said to be ludicrously faster than Net::HTTP), so use the net-http-persistent gem. The implementation is quite clean and simple and the documentation provides recommended Net::HTTP APIs to use with it.

With no offense intended towards the curb maintainers, it appears that the performance problem was introduced six months before the fix, took seven releases to be noticed and six more to be properly diagnosed. I've seen lots of grumbling about performance in the ruby community but it appears that the grumblers are more likely to repeat somebody else's complaints instead of investigating the problems and proposing solutions.

Net::HTTP API

The Net::HTTP API may appear clunky, but it provides many ways to do the same thing for programmer convenience. For the majority of my usecases I use only this:

require 'net/http'
require 'uri'

u = URI.parse 'http://blog.segment7.net/'

http = Net::HTTP.new u.host, u.port

request = Net::HTTP::Get.new u.request_uri

response = http.request request

I typed this out of memory without consulting the documentation!

I will admit that the API documentation is organized to get you up and running quickly with the convenience methods instead of explaining the best way to use it until much later (Example #4 for GET+print, Example #3 for POST), but this is a relatively easy thing to fix.

Net::SMTP

I wrote ar_mailer which sits atop Net::SMTP. I had to add one monkeypatch to Net::SMTP, support for RSET (and I'm a bad person for not committing it to ruby). Everything else is handled easily by Net::SMTP. I don't see how you could argue that it is old or has a crufty API as the SMTP protocol hasn't changed much over the years.

Net::IMAP

I've written several IMAP tools to read my email for me. Net::IMAP has been very pleasant to work with. I've even contributed support for IDLE to Net::IMAP. I don't see how you could argue that it is old or crufty as I've found it relatively easy to support the various IMAP extensions.

WEBrick

I'm probably one of the few people who has used WEBrick in large-scale production. I served millions of HTTP requests with WEBrick at about half the speed of apache (I believe WEBrick took 25ms to serve a static image as opposed to apache which took 12ms).

WEBrick has a wonderful API and features built-in CGI, SSL, cookie handling, Basic and Digest authentication along with multiple methods of password lookup, Proxy, SSL and an easy to use handler API.

What WEBrick is missing is the process control features provided by other ruby web server like mongrel or unicorn.

REXML

We all know that REXML is not the best and Nokogiri is the best XML library in ruby, but replacing it has many issues to resolve.

DRb and Rinda

These two libraries are beautifully simple and provide an excellent example of the power of ruby. There's a terrific amount of fun you can have with these two libraries.

Net::FTP, Net::POP, Net::Telnet, RSS

I've never used any of these libraries and can't say anything good or bad about them. I'd like to see concrete reasons why they should be removed.

Making the Ruby stdlib Better

Mike wants Ruby to get a good spring cleaning but is only proposing outright removal. I don't see how this is at all constructive or improves any issues.

If you have actual problems with these libraries what are they? Have you filed a ticket? Can you fix them? Have you submitted a patch?

When I found the problems with curb I didn't just complain about them, I took the about half a day to figure out what the root problems were and filed tickets as I found I wasn't capable of fixing the problem. This involved digging around in man pages, reading the curb C extension and fiddling with strace. I took the time to make curb better even though I'm probably never going to use curb outside of a benchmark.

Asking the questions "what is wrong?" and "how can I make it better?" makes ruby better for everyone, it's what open source is about.

Saying "we should just remove stuff" without a plan for what it's going to be replaced with and how we're going to avoid breaking existing libraries is nothing more than harmful whining. If you want to see the standard library improved you need to sit down and get to work on making it better or replacing it with something that has the same features and more.

Recent stdlib Improvements

Ruby 1.8's YAML is based on Syck which was written by _why. Even before _why left ruby there were numerous unfixed bugs in Syck. Aaron Patterson attempted to fix these bugs but eventually gave up and wrote a new YAML implementation based on libyaml called Psych. Psych supports the same API as Syck and is an excellent example of how to improve the standard library.

Ruby currently uses a pure-ruby implementation of Date and DateTime. Jeremy Evans has written home_run and is attempting to import it into 1.9. There is currently an objection due to possible incompatibilities between the current date.rb and home_run but these should be resolved shortly.

Aaron's Psych and Jeremy's home_run show that the ruby maintainers are willing and ready to accept replacement of parts of the standard library. I think the expectations of the core team are both fair and reasonable as they are designed to minimize breakage of existing ruby software.

Ruby's stdlib is only a ghetto if you treat it like one.