Ruby 1.9.1 was released today. You wouldn’t know it from the version number “1.9.1″ but this is a big deal in the Ruby community. It’s the Python 3000 of Ruby, except it’s an even bigger deal than that because it’s not only a bunch of backward-incompatible language changes, but it’s also a totally new implementation with much better performance than the Ruby 1.8.x line.
I’m glad to see this release, because I was starting to worry it would never happen, sort of like Perl 6. Now that Perl 6 has become the Duke Nukem Forever of programming languages, I was worried that Ruby 2.0 (oops, 1.9.x now) was going to suffer the same fate, and cause stagnation in the Ruby community.
But now it’s out, and the performance number show it still lagging behind Python a bit, but significantly faster than Ruby 1.8. It also apparently has native threads, which Ruby 1.8 did not.
I like Ruby quite a lot as a language. But I’m finding it harder to buy into its culture and its future. One major example is the documentation (or lack thereof) that accompanies this release. Being that this is a major release with major improvements and backward-incompatible changes, you would expect a great deal of information about what has changed. But here is what the “NEWS” file (their release notes) looks like:
NEWSThis document is a list of user visible feature changes made between releases except for bug fixes.
Note that each entry is kept so brief that no reason behind or reference information is supplied with. For a full list of changes with all sufficient information, see the ChangeLog file.
Changes since the 1.8.7 releaseSee doc/NEWS-1.8.7 for changes between 1.8.6 and 1.8.7.
Compatibility issues
- language core
- New syntax and semantics
- Block arguments are always local
- New semantics for block arguments
- defined? and local variables
- Parser expects that your source code has only valid byte
sequence in some character encoding. Use magic comments
to tell the parser which encoding you use.- New semantics for constant definition in instance_eval
or in module_eval.
And so on, for pages and pages. This list is meaningless to anyone who isn’t already familiar with the changes that have been happening in Ruby 1.9.x. There’s simply no way to know what any of it is talking about. Now the top of the file claims that the ChangeLog has rationale and reference information, but take a look for yourself: it isn’t any better.
Not to mention that there appears to be absolutely no documentation accompanying this release. No documentation about the language, no documentation about the libraries (it’s probably possible to generate some using rubydoc, but no pre-built version appears to be available anywhere), just none. The one document that’s included about writing extensions makes absolutely no mention of threads, despite the fact that Ruby now has threads (which presumably extension writers have to deal with somehow).
And while one would like to think that it’s just a matter of time, my experience with Ruby libraries is that you come to expect very sparse and under-documented stuff like this.
Like I said, this is disappointing to me, because Ruby is my favorite language of its kind. I’ve written a lot of Ruby. Hell, at Amazon I started what I called the “Ruby Revolution,” and poured tons of time and energy into it. But although Matz has designed a very nice language, the support structures around that language seem more and more amateurish the more I think about them.
I mean, I’m just one guy, and Gazelle has approximately zero users at the moment, but I still write up descriptive release notes and have an extensive manual.
But for a more fair comparison, look at Python 3000. Look at its list of what’s changed since Python 2.6, for which every changed references a more detailed “Python Enhancement Proposal” which gives rationale and yet further references to discussion. And look at its list of documentation: a tutorial, a language reference, a library reference, detailed information about extending and embedding, and more. It makes Ruby’s lack of documentation even more stark.
To be fair, the Pickaxe book has always been Ruby’s unofficial manual, and it appears that the Ruby 1.9 version of the book is already in “beta”. I think I’ll buy a copy just so I can have some idea of what the heck is going on with Ruby 1.9
But it’s still hard to shake the feeling that Python is more mature, and a safer bet.
A bet for what you ask? I have another project (something impractically big and ambitious) kicking around in my head for which something like Ruby or Python is the right answer. And I’ve been trying to decide which way to go…
Update: I did just think of one significant difference between Ruby 1.9.x and Python 3000. The difference has to do with character encoding. Python has taken an “everything is Unicode” approach to character encoding — it doesn’t support any other encodings it doesn’t support any other character sets internally, which means that round-trips from any encodings that are not injective onto Unicode are lossy (revised to speak more precisely, since many people took the wrong meaning from my original wording). Ruby on the other hand supports arbitrary encodings, for both Ruby source files and for data that Ruby programs deal with.
This is one issue about which Ruby seems like the somewhat safer bet. “Everything is Unicode” seems fine to us westerners, but apparently isn’t not as favored by people from Japan. I can’t find a reference now, but the two biggest reasons seem to be that Japanese characters all get blown up to 2 or 3 bytes or something, and Han Unification which means that unless you get the font right, a Japanese character can get displayed as the corresponding Chinese character with the same meaning.
But regardless of the reasons, putting all your eggs in one encoding basket (as Python has done) seems less future-proof than supporting arbitrary encodings, as Ruby 1.9.x does. +1 Ruby.