Don't let the title fool you. On the whole, I love Ruby. But, like any programming language, there are some things about it that really bug me.
- Ruby is slow.
With very few exceptions, it has been my experience that Ruby is just plain slow when compared to other interpreted languages like PHP, Perl, and Java. There are plenty of reasons for this, but it's not hard to find places where performance could be improved just by poking through the source code of the Ruby interpreter for a few minutes. That's not very comforting.
Hopefully the eventual move to YARV will improve things, but that brings me to my next point...
- Ruby's development process is slow.
By which I mean that the development of the Ruby language itself is slow, not that developing software using Ruby is a slow process (it isn't).
Ruby's development status is hard to get a handle on because there doesn't seem to be any single source of reliable information other than Matz himself. The fact that I don't speak Japanese makes it even more difficult, because many of the core Ruby developers don't speak or write in English.
Not that the communication issues really matter, because not much ever really seems to happen with Ruby. Sometimes six months or even a year will go by between minor releases. That can be very frustrating.
- Ruby's "official" documentation is sparse and, in some cases, nonexistent.
Learning the basics of Ruby isn't very hard; there are plenty of beginner's guides out there, including the brilliant Why's (Poignant) Guide to Ruby, but once you get past the basics and want to really get your hands dirty, you're going to find yourself doing a lot of Google searches and coming up empty a lot of the time.
Ruby (and most other programming languages) could learn a lot from PHP in this respect. The PHP documentation isn't by any means perfect, but it's organized in a sensible way and the user comments often provide valuable clarifications or examples when the documentation itself falls short.
Ruby's official docs don't seem to have been written with much care. The latest revisions have even inexplicably removed all documentation for the Kernel object, which contains some of Ruby's most important and frequently-used features. I emailed the maintainer about this several weeks ago and even got a response, but they have yet to do anything about the problem.
- Screw the Ruby Way, sometimes I just want to get things done.
Spend any time using Ruby and you'll hear a lot about the Ruby Way. People love to talk about Ruby as if it's a religion rather than a programming language. The term refers to Ruby's general philosophy of simplicity, elegance, and adherence to the Principle of Least Surprise.
On the surface this seems like a good thing, and it really should be, but the truth is that the Ruby Way is different depending on who you ask. And since Ruby programmers can't stand the idea of implementing something in any way other than the Ruby Way, they'll often end up spending days, months or years talking about the best way to implement something without ever actually implementing it. Spend five minutes trying to find actual solid information in the RubyGarden wiki and you'll see what I mean.
- Ruby has shitty XML support.
There are two reasons for this. The first is that the Ruby crowd seems to have a beef with XML. They'd much rather force you to use YAML, even though there are plenty of situations in which YAML is absolutely the wrong tool for the job.
The second reason for Ruby's shitty XML support is that nobody can agree on the Ruby Way to implement XML support. So we're stuck with REXML, a slow, buggy, incomplete XML processor that provides an API that bears no similarity to the XML API of any other programming language. Most languages provide out-of-the-box support for the DOM API and perhaps one or two other standard APIs, but not Ruby. You either use REXML or you use (or write) a third-party extension and make your application less portable.
My hatred of REXML is a personal matter, obviously, and there are plenty of people who like it, but the problem is that there aren't alternatives. At least, not as far as Ruby's standard libraries are concerned. And I hate that, because as much as I like YAML, I often prefer to use XML, and using XML in Ruby is a pain in the ass, so I generally end up using PHP instead.
Comments
I hear you...
On the other hand, *generating* xml in Ruby is a blissful experience, thanks to the Builder library. Not only is it brilliantly designed, but the developers are responsive and friendly.
Re: I hear you...
I haven't tried Builder, but I'll take a look at it. It's not a standard library though, which is what I was getting at. There are a number of REXML alternatives, but using them means giving my application dependencies outside the Ruby standard libraries, which is a big inconvenience for me and my users.
REXML ain't that bad
What about the "pick-axe" for documentation?
Re: REXML ain't that bad
The Pickaxe book is good, but the edition available online is badly outdated and even if I bought the updated second edition, it'd be a pain to have to look things up in a physical book. Using online documentation is sooooo much more convenient.
Ok, Ruby Slow -> My Thumb up
I admit it, no such benchmark required. I can see it and feel it. for example, I create 10000s class objects, takes 1 min+, same algorith written in Java takes 5 seconds.
I think Ruby just needs some core shit done properly, such as prechaching, buffer allocations, etc.
Pickaxe2
You can get the Pickaxe2 book in PDF format if that helps. It truly is a great book. Ruby does need a better documentation format. I love the PHP implementation ... I thought someone was working on bettering this, but not for sure anymore. Personally, I've learned tons by studying well-written code such as Rails (most of it).
Performance, and I dislike REXML too!
I agree that Ruby has some performance problems; supposedly 1.9 and/or 2.0 are going to resolve a lot of those issues. From what I've heard, they're going by the usual agile approach of "first make it work, then find bottlenecks and improve performance." Given how much simple closures (e.g. [].each) add overhead when I profile simple stuff, this definitely needs work. Heh, heh... but this does lead into your #2 item. When will 1.9 be stable? When it's finished. When will 2.0 be done? Nobody's sure it ever will be done.
However... I've found that, once you learn where Ruby's clunky, performance problems tend to be pretty easy to resolve. The overall language is still slow, of course, but I've found it pretty easy to eliminate bottlenecks, often without even busting out the profiler.
As for REXML... I found this post while Googling for 'REXML alternatives,' because I'm getting close to giving up on the damn thing. The syntax is anything but the Ruby Way (which I personally have a rather lax view on; for me it means some few formatting conventions and extensive use of method_missing, blocks and mixins to quickly implement the Gang of Four patterns in subtle ways). Personally, I can't stand its method conventions - to find one element of the node by XPath, use parent[query], but to find multiple, you use parent.each(query), etc. I've lost hours of cross-checking the manual to remember how to get anything useful done - it definitely doesn't follow the principle of least surprise. And its XPath performance is rather frightening; I've been able to reduce query time by 33%-50% when doing simple searches (e.g. '//somename | //somename2') by simply using doc.root.each_recursive and checking the element names myself! (Of course, maybe that's true with most frameworks... but come on! It's a 550 line XML file, maybe 800 elements; it shouldn't take two seconds to do a trivial XPath!)
Still, I get a lot more done with Rails now than I ever did in C#, so I'll just keep grumbling when I hit these hotspots. =) I'm with you - I love Ruby, but the gotchas really getcha.
No title
REXML inspires much loathing in me. In good news, the libxml bindings are actually getting some love. The project could use more help, but at least it's there.
No title
Love Ruby, but REXML is so slow that it will not functionally work for a current project.
Faster XML parsing in Ruby
http://code.whytheluckystiff.net/hpricot/
Re: Faster XML parsing in Ruby
Hpricot is a very nice HTML parser, but it's not a general-purpose XML parser.
No title
This really pisses me off :-(
No title
I suggest you do google search about Ruby books. That will clear many of your hatepoints against the programming language.
Mrs
It is over rated and the development process is poorly layed out. I honestly hate the language.
I can do the same thing in JSP and far faster. It irritates me when kids find some new toy and push it out.
I have been forced to use it and will now resign from my job because it is a total waste of my time.
na
DongJin wrote: "I admit it, no such benchmark required. I can see it and feel it. for example, I create 10000s class objects, takes 1 min+, same algorith written in Java takes 5 seconds. I think Ruby just needs some core shit done properly, such as prechaching, buffer allocations, etc."
That's pretty bad. I recently had to initialize 1 million objects in python and it took 15 seconds to do. I was actually able to disable the garbage collector for the time of the creation of the million objects, after which I enabled the GC. This further improved the performance down to 3 seconds.
Who care about speed?
now a days system are getting faster and faster, why care about speed of a language?
Who cares about speed? I do
I loved working in Ruby when I did. But it’s slow.
YARV may fix this, if Matz gets around to working on it again. I haven’t been following other VMs, but the last update seems to have been in 2006. That’s approaching the Perl 6 for lateness (ok that was a stretch).
Slow code is expensive. For big websites, it means more servers, higher % CPU utilization, pricier electric bills.
Having said that, I don’t recommend writing web sites in assembly, offloading to the graphics card. heh.
I care too!
Systems actually have stopped getting faster and faster, at least the processors. You don’t see the average processor going much higher than 3-4GHz, when according to Moore’s Law we should be a lot higher than that by now. Today we’re seeing things go more and more parallel (dual core, quad core, etc.) and until Ruby improves its thread support (green threads don’t take advantage of multi-core systems) it’s going to remain beastly slow.
Slow code is expensive yes, but it’s not usually the code that will slow your site down. Usually it’s the database or the other content like images. You have to be really big before the code becomes your slowdown. In the case of Ruby, it tends to be the beastly frameworks like Rails that cause the site to be slow, and (from my experience with Ruby coders) the Ruby way tends to produce slower code than other ways.
Speed matters still
It isn’t really the ruby way that produces slow code it is the Rails way, at least from my limited experiene. Other Ruby frameworks and libraries aren’t necessarily as horribly slow.
I think the Rails developers just ignored performance when they developed their framwerok which is what has caused it to be terribly slow. Slower than Ruby should be even when Ruby is quite a bit slower than Python and Perl.
For exampel I could eaisly write an JSON serializer of active record objects that was about 20 times faster than their serializer for the purpose I was using it. I still haven’t managed to figure out what is wrong with their code, thetricky parts of JSON which I ingore (and they too to some extent) shouldn’t make this differnce. And this was comparing two pure ruby implementations. A C implementation should have been even faster, so why don’t they use the already existing JSON library for ruby written in C?
Speed
“now a days system are getting faster and faster, why care about speed of a language?”
Such a cliche.. “Who cares about speed”, “why care about memory” etc etc..
Why do you think tech companies make systems faster and faster? If they are too fast already?
You’ll learn by time…
Bottlenecks
“but it’s not usually the code that will slow your site down”
Depends on what you do in the code, how many times you repeat it, and the overhead of other stuff like images, db access etc.
Eg. You may have a website with no images, no db access and some heavy loops in the code.
Java is not interpreted
Sorry, but I stopped reading after you said this.
Java is interpreted
Although it can be compiled to machine code or run by a just-in-time compiler, Java is most often compiled to bytecode which is then interpreted by a virtual machine (just like PHP, Perl, and many other interpreted languages).
For what it’s worth, snarky comments work best when they’re actually correct. Otherwise they just make you look like an asshole.
NB
Might I add that “interpreting” Java code and Java byte code is not equivalent. The Java compiler (which compiles to byte code) makes certain optimisations that simply don’t happen with PHP/Ruby/Python/Perl interpreters.
Not anymore
Not sure whether this got lost, but I posted this before the previous comment.
Older JVM’s simply interpreted Java byte code (which is compiled from Java code), but newer ones use something called a “Just In Time” compiler, which compiles the bytecode into native instructions for speed.
Also, good on you for calling your readers assholes. :)
Compiled
Actually, Perl and Python are compiled, too
Reading comprehension
Your reading skills leave much to be desired.