Ruby Stdlib is a Ghetto, Pt. 2 | Hacker News Reader

Ruby Stdlib is a Ghetto, Pt. 2

mikeperham.com

45 pointssteveklabnik14 comments

Mike's a great guy, and I appreciate his post but would respectfully disagree with the proposal to strip the standard library down to barebones and break out the removed classes into gems (along with the post's title to which I object, but will not take issue).

Despite its lack of use in web projects, DRb is one of Ruby's most interesting modules. Geoffrey Grosenbach's recounting of _why's 2005 FOSCON presentation is among the highlights - see here for an example: http://www.smashingmagazine.com/2010/05/15/why-a-tale-of-a-p...

The English RDoc is eminently fixable as well, whether by a core contributor or not. In fact, the first commenter on the post highlights a quick guide to contributing to the language.

More importantly, the process for formalizing the Ruby language into an international specification is progressing nicely, first with Japan's ISC committee, and later with ISO. While the draft specification is restricted to the language itself and does not include several components of what we know as the standard library, it would be prudent for the language itself to continue to stabilize. You can find the 12/2009 draft spec here: http://ruby-std.netlab.jp/draft_spec/draft_ruby_spec-2009120...

Finally, many groups of developers have made tremendous progress on non-MRI/YARV implementations, such as JRuby, Rubinius, IronRuby, and MagLev, with others such as SAP's BlueRuby continuing to show promise (passing over 75% of RubySpec as of last year). Sweeping changes to the language and standard library impedes the maturation of these implementations, placing additional burden upon their developers and sponsors who are already doing tremendous work to advance the state of the language across multiple platforms.

We would also do well to remember that the community of English-speaking web developers using Ruby represents a small subset of the Ruby community as a whole. Though some of us might not find daily use for all of the modules in the standard library, it needn't be assumed that they should be removed and/or broken out.

Many languages experience similar growing pains. The Python standard library contains a few modules which seem out of place to most web developers, the JDK is a bit of a grabbag, and the .NET class library has a handful of oddities. Nonetheless, it's important to remember that many people use these components and they work quite well. What some may decry as cruft and stagnation, others might regard as a sign of stability and maturity.

What I appreciate most though is the civility of this discussion. Between Mike's first post, Eric's reply, and this follow-up, the conversation's professionalism and camaraderie is impressive. It's great to see programmers coming together to discuss improvements to the language and its direction in a calm, refreshing environment. I haven't written much Ruby in the past year, so it wouldn't be appropriate of me to offer an extended post as a reply, but I'm glad to see the discussion happening.

I agree. Mike is a great guy but the flamebait headlines are really not necessary.

I am more of a Python guy but being a language enthusiast I like to learn and experiment with other languages. Ruby the language is something that I found to be beautifully designed and I really like a lot of its concepts (especially pure OO and blocks which come from Smalltalk). While I know Ruby by writing small scripts and reading the pickaxe book, I have really been wanting to use Ruby in a medium scale project. These sort of articles scare me. Some of the reasons why I haven't gone into Ruby fully are:

* Most of the information is web/rails centric. I generally write unix server apps/tools which have nothing to do with the Web.

* The standard library packages have weird names so its difficult to find. E.g. With DRb it wasn't immediate to me what it does.

* The stdlib documentation is a little lacking. I read the pickaxe book but the stdlib documentation doesn't compare with what I am used to with Python.

* Based on the posts I have read it seems to me that there are multiple libraries that do the same job. So it becomes difficult for a noob like me to know which lib I should invest my time in.

* Articles like these are scary for a Ruby noob like me. For example, I was excited about DRb when I first read about it. Now, in the first of these 'stdlib is ghetto' articles, apparently DRb is not very nice. Thats just confusing to me.

I think Ruby is a really neat language but the Ruby community needs to stop confusing people who want to try it out.

While your concerns have merit, the overall picture is not nearly so bleak.

Yes, the stdlib docs need some love. I've tried assorted approaches to rousing interest, and now consider it a dead end. A handful of people have done a terrific job in improving what was a once worse situation, and everyone who uses Ruby should be grateful to them, but there's much more to be done.

Still, you can get often excellent help on ruby-talk or #ruby-lang on freenode.

I feel your pain about available info being Rails-centric; I don't know what the answer there is. Careful Googling perhaps. " -Rails" is your friend.

I like having multiple libraries for things. I ask around, get some advice, maybe try some out, and life is good. Really, it's not a big deal.

And Drb is really sweet, and fun to play with.

"I think Ruby is a really neat language but the Ruby community needs to stop confusing people who want to try it out."

Actually, it's various individuals expressing their own opinions. Take it all with a grain of salt.

BTW, if you decide to dig fully into Ruby and have questions, feel free to drop me an E-mail. My addy is in my HN profile.

I like having multiple libraries for things...Really, it's not a big deal.

Right up until the point you try to deploy your program over a large number of platforms. Sure if all you're doing is hosting a webapp on a server you control (which seems to be the main use case for Ruby), then it's not a problem. Once you start trying to deploy on platforms you don't control a complete standard lib becomes really handy.

That is one reason I really like python. I can say something like "install any version of python 2 after 2.6.2" and that's all they need to worry about. There is very little you cannot do using only the standard lib. No hunting for and installing third party libs with all the troubles that can cause.

Obviously I'm not arguing against third party libraries. I use and love many in python. But the fact that they are optional in most cases is really handy.

Why can't you just bundle the libraries with your app?

I'm not sure I agree with your argument. All but the simplest Python/Java/C++/.NET apps also require third party libraries.

As one of the authors of Phusion Passenger, I've found Ruby to be an excellent tool for writing Unix server apps/tools. Maybe not high performance servers (the Phusion Passenger core is in C++) but it's perfect for servers in the low to mid performance range that you want to write quickly. Ruby is very, very, very good for writing things like sysadmin tools and installers. The Phusion Passenger and Ruby Enterprise Edition installers are written in Ruby and it was a much more enjoyable experience than writing such things in bash.

As for multiple libraries, each language has multiple libraries with the same purpose, Python is no exception. If you want to know which one is best for your purpose you can just ask on StackOverflow these days.

DRb works. It's not broken. There are just two issues:

* Documentation can be better. It seems people haven't worked on its documentation for a while now.

* Few people actually need DRb.

"ghetto" here doesn't imply that the stdlib is a horrible broken mess, it implies that some things are better split outside the core Ruby distribution.

"The Ruby community, at least in the US, has proven to be very open to change, see Rails 1, 2 and 3 for example. "

That's change?

That's like saying you've moved from sliced cheese to cheese on white bread to grilled Swiss on toast, and claiming to be open to new tastes[0].

Were there a real appetite for change there would be far more enthusiasm for the dozen+ Ruby Web frameworks instead of the increasing Ruby is Rails is Ruby mantra.

(There's a selection bias in my observation; people open to change often don't self-identify as <language>-ists; they're busy using a variety of languages and libraries. The "Rubyists" open to change are using Clojure, Haskell, Lua, and Go. :) )

Referencing Chad Fowler is sort of ironic, given that he had stood before a Ruby conf crowd and told people to stop working on Nitro; Rails had "won", so there was no need for a competing framework.

Why not declare that REXML "won" (it's in the std-lib after all), that we don't need competing libraries, and leave it at that? Because, as with Web frameworks, that would be stupid.

It's worth noting that REXML got added to the standard lib because of the belief that Ruby should "do XML" out of the box. I have no idea if that's still a compelling argument, though enthusiasm for anything XML has, let's say, diminished. Assuming the low friction of installing gems as needed, and advances in non-std lib gems, it's really hard to argue for keeping it in. But REXML was a gem at the time of its inclusion, there was no great love for XML, and people still wanted to bundle it in.

None of this is new; the debate started as soon as rubygems was reasonably stable, and perked up again once rubygems was moved into Ruby proper. The biggest arguments against splitting out the std lib were that some people work under constrictive code installment policies (so just grabbing gems as needed can be an issue), and that there is an advantage to vetting broadly useful libraries to ensure they play nice with the rest of the core code (i.e., you don't end up with a DB lib that modifies Object or Class with surprising results).

[0] It also reminds me of a line from "The Blues Brothers", "Oh, we got both kinds [of music] -- country and western"

Yes, that's change. With "change" the author meant API-breaking changes, not fundamental paradigm changes. The latter is irrelevant for the point he's making.

What API-breaking changes? Moving a library from stdlib to a gem doesn't change the API of the library.

About the only difference is having to invoke rubygems before the require.

However, changing what people can expect by default in a standard Ruby installation is more of a paradigm change (albeit not terribly grand).

API breaking changes such as Rails 2 -> Rails 3. Read the article.

A few people in the discussion seem offended by the term "ghetto" in the article's title. I thought I'd point out to those unaware that this is a tongue in cheek reference to the infamous Zed shaw article in which he combines a critique of Rails while listing off his martial arts skills.

(On http://www.zedshaw.com/rants/rails_is_a_ghetto.html the article is no longer up there but it can surely be found with some googling if you are interested.)

I think part of the issue is that different people expect different functionality from a "standard library". I see three logical divisions within the language we call "Ruby":

1. Core language - Definition of language syntax and literals, regular expressions, core data structures

2. Standard library - Functionality that is expected out of a programming language (not framework) - things like file reading, ERb, etc.

3. Standard protocols - A set of libraries with the default Ruby implementations for standard protocols - HTTP, JSON, SSL, OpenId, etc.

It seems to me like protocols don't belong in the same directory as libraries for basic local file operations, but maybe that's just me.

Either way, I think the standard library, while not a ghetto, could use more order and care.

> It seems to me like protocols don't belong in the same directory as libraries for basic local file operations

They aren't. File is in core, net/http is in stdlib. FileUtils is in stdlib, but that's more about interaction with the filesystem than files themselves, and it's not necessary for every single ruby script the way File is.

For the most part, I think the core/stdlib separation is ok. What I take issue with is the namespace organisation, especially in stdlib. I'd rather see a deeper hierarchy that avoids stomping on the top-level namespace than what we've got now, but that's a lot of work to reorganise.

Reply on news.ycombinator.com