...especially about the REXML part. Personally, for DOM parseing, I think that Dom4j really "got it right". There are so many things in REXML that *almost* seem to work the way you'd expect... and then utterly fail to.

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.

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.

The SOAP library is really terrrrrrible. It is called "Soap4r" or something like that, I don't remember because it was so bad I ended up doing every SOAP transaction manually.

What about the "pick-axe" for documentation?

REXML's API just grates on my nerves at some fundamental level.

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.

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.

I know this is a relatively old post, but I just found it so ...

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).

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.

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.

Love Ruby, but REXML is so slow that it will not functionally work for a current project.

give hpricot a try, it is much faster than REXML

http://code.whytheluckystiff.net/hpricot/

Hpricot is a very nice HTML parser, but it's not a general-purpose XML parser.

On Windows performance is even worse... I run ruby on the same notebook under Ubuntu and WinXP (dual boot) and there on Windows it's like slow motion on the VCR...

This really pisses me off :-(

I suggest you do google search about Ruby books. That will clear many of your hatepoints against the programming language.

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.

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.

now a days system are getting faster and faster, why care about speed of a language?

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.

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.

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?

“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…

“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.

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.

Sorry, but I stopped reading after you said this.

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).

Java: A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, dynamic language.

…

Java bytecodes are translated on the fly to native machine instructions (interpreted) and not stored anywhere. And since linking is a more incremental and lightweight process, the development process can be much more rapid and exploratory.

— The Java Language: An Overview

For what it’s worth, snarky comments work best when they’re actually correct. Otherwise they just make you look like an asshole.

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 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. :)

Actually, Perl and Python are compiled, too

Your reading skills leave much to be desired.

Many of the points mentioned here have seen at least some improvement [thank goodness], with 1.9
1) Ruby is slow: well now it’s slow but not AS slow.
2) Ruby development is slow. Jruby seems progressive, and bugs to 1.9 get fixed reasonably fast. Real development is still slow, though.
3) Documentation is sparse: it is still basically ugly and sparse. The kernel docs are back though, it seems.
4) The ruby way is ill definfed. Yeah—like a good rubyist I do it my own way, too, not the ruby way.
5) xml support: at least now there’s hpricot and nokogiri, so a move up.
Cheers!
-=r

re: rails is slow—yeah it really is. Though it has improved slightly with the later releases. At least they “kind of” care about speed now.
re: ruby on windows is slow. Yeah it is—try the mingw builds they are much better. http://www.akitaonrails.com/2008/7/26/still-playing-with-ruby-on-windows

1. fixed
2. fixed
3. fixed
4. bullshit…
5. fixed

I love the way you answered number 4. lol

Number 4 is bullshit now. It certainly wasn’t bullshit in 2005 when this post was written. Ruby has come a long way. I’d actually argue that #1 and #4 are the only things that have been fixed. 2, 3, and 5 are still problems.

I really love writing apps in ruby, but unfortunately it is so slow that we had to drop it in our shop. And yes, we tried every trick available, but it has some fundamental issues that won’t be resolved any time soon.

I don’t agree with the documentation part though – I alway found it sufficient.

Was kinda interested in Ruby until I learn the basics of Ruby and read this:

Yukihiro Matsumoto: Ruby inherited the Perl philosophy of having more than one way to do the same thing. I inherited that philosophy from Larry Wall, who is my hero actually. I want to make Ruby users free. I want to give them the freedom to choose. People are different. People choose different criteria. But if there is a better way among many alternatives, I want to encourage that way by making it comfortable. So that’s what I’ve tried to do. Maybe Python code is a bit more readable. Everyone can write the same style of Python code, so it can be easier to read, maybe. But the difference from one person to the next is so big, providing only one way is little help even if you’re using Python, I think. I’d rather provide many ways if it’s possible, but encourage or guide users to choose a better way if it’s possible.

I’m started to wonder whether it’s just another language with community comprise mostly of newbies, for instance,

arr = []
arr[100] = 'A'

This auto resizes the array to 100, what the …. This was exact the mentally when I was learning programming 20 years ago, a stupid kid wanted not to care about array size. Don’t tell me you guys think this is a good feature!? God knows how many “surprises” await me!?

Python seems to have a healthy community with experts and hackers, I had better learn more about Python.

By the way, I’m a Java guy.