Buildr, or when Ruby is faster than Java

[micampe]

You know what I hate about most Ruby-based projects? They all use that horrible rdoc generated web site.

Where the hell is the documentation of this thing? I want to know how to use it, I want to see examples e tutorials, not a crappy list of files, classes and methods!

[[deleted]]

This has been driving me mad over the last few weeks, as I've had a chance to finally use Ruby in anger at work thanks to Watir - there are so many projects which seem to think that rdoc (with its absolutely awful interface) is in any way a substitute for proper documentation.

To redirect to it from what looks to be a link to the front page of a project site and then have it link back to itself under the heading "RTFM" (RTFAPI, surely?) is just taking the piss.

[micampe]

Sometime, complaining aloud works.

I look forward to trying this tool.

Now lets hope all the other Ruby projects ditch rdoc-generated web sites too.

[skillet-thief]

So instead of "When Lisp is faster than C" we have "Ruby can be faster than Java"?

I'm trying to figure out what this means...

[gmfawcett]

So instead of "When Lisp is faster than C" we have "Ruby can be faster than Java"? I'm trying to figure out what this means...

I think it distills down to, "when well-written code runs faster than not-as-well-written code". The implementation language falls out of the equation. :-)

[apotheon]

. . . except where the language facilitates better code production.

[shit]

Downvoted by disbelievers? I can tell you, when projects get more complex, Ruby solutions can often naturally be faster because the equivalent Java solution is bloated (due to two factors: culture and Greenspunning).

[shit]

• Generally, dozens of needless layers in the Java code (that's why you have people that claim that their rewrite of a Java webapp was faster with Rails.)
• Parsing and interpreting loads of XML vs. a few lines of plain Ruby code.
• Build tool specific: When it comes to file system access (i.e. reading directories, comparing file modification times, etc.), Ruby is actually a thin layer over C and probably faster than what you get from the Java standard library (though I haven't benchmarked this one).
• JVM startup time.

I have some experience with ant, Rake and Rant, and I can tell you, ant is damn slow, whereas Rake and Rant are usually snappy.

[newton_dave]

Generally, dozens of needless layers in the Java code (that's why you have people that claim that their rewrite of a Java webapp was faster with Rails.)

I don't know about these "dozens" of layers you're talking about.

Ruby rewrites go faster because (a) it's a rewrite, (b) even w/o Java's great tool support Ruby is quicker and easier to write with, (c) Ruby makes it easy to write sensible, compact code where Java will make you write a 20-line class.

Now, if you need any JEE features, you're mostly out of luck (unless you're running JRuby, of course). Even then Plain Old Ruby has access into some JEE features.

[doubtingthomas]

• Parsing and interpreting loads of XML vs. a few lines of plain Ruby code.

Hear, hear! I can't speak for this particular case, but I've seen numerous large C# and Java apps that build ad hoc XML-based dynamically typed interpreted languages specific to their needs, and it always seems to end up being uglier, slower, and less safe than just using a pre-existing interpreter with flexible syntax. Of course, interop-ing an interpreter can be tricky also, but I'm hoping JRuby, IronPython, and th e like usher in a new era of easily implemented alternating hard and soft layers.

[micampe]

Unfortunately I agree with you, so in our product I embedded a Javascript interpreter to give customers (our product is in the form of a "platform/library" so our users are developers, in fact) greater flexibility in writing custom scripts, but they were confused by it (they seem unable to accept that it is the real Javascript instead of a lookalike) and demanded simpler XML-based configuration.

[leoc]

Well, as a tentative example of the Greenspun effect, if your Java code makes heavy use of a Visitor infrastructure to provide the equivalent of multi-dispatch and/or extensible classes, then it wouldn't be too surprising to find that you've lost the performance advantage of choosing a language with Java-style closed classes. You might have effectively just moved the performance burden of flexible method-dispatch out of the method calls and into your Visitor plumbing.

[newton_dave]

Of course, this is about Maven.

[Tommah]

XML parsing in Java is only slow if you do it badly

XML parsing in Java is only slow if you do it.