Groovy and Ruby « Head On

Groovy and Ruby

I cannot help myself from making a small comment on Rick Hightowers post on Groovy vs JRuby. In short he thinks Sun should support Groovy instead og JRuby, because the syntax is familiar to Java programmers.

To support his case he presents a chart showing language popularity according to job postings. And since Ruby is at the bottom and Java is on the top, Sun should support Groovy. Which by the way is not even on the chart.

One thing I did recognize was this:

Notice that between Java and Ruby/Python there is a wasteland of languages that you will not see running on the JVM in any near future. So if Sun wants to expand the developer base for the JVM (not Java the language), I believe they are making a very wise decision to support the largest languages available to them outside of Java.

Supporting Groovy would probably be popular among the already converted, but Sun has to appeal to new markets to expand the JVM usage. I believe that is what they are doing.

Tags: Java, Ruby, XP

This entry was posted on Thursday, January 17th, 2008 at 13:19 and is filed under Java, Programming, Ruby, Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Marcus

Graeme and Danno, thanks for your clarifications. I stand corrected.

Danno Ferrin

It should be noted in the huxili paper the test methodology is not the norm of how a runtime Groovy application works, particularly grails. The same script is not compiled over and over again, it is cached once and re-used over and over again, whereas the example the paper is based on uses what appears to be something based on JSR-223 style invocations, where the better examaple may be to use javax.script.CompiledScript. All this paper does is demonstrate the intepreted vs. compiled nature of Ruby vs. Groovy.

A better and more real-world case of memory use would come from calling a compile GSP page 7000 times or a page generated by JRuby on rails 7000 times.

Graeme Rocher

That report is complete nonsense. Firstly it shows no code which for such an official looking report is ridiculous. Second I can pretty much guaruantee the problem is that huxili is using the same GroovyShell instance the whole time instead of creating a new one each time.

The result is the GroovyShell's class loader (and hence the classes) are never garbage collected. Besides it is easy to find and point out scalability issues in JRuby too if you dig hard enough:

http://groups.google.com/group/jvm-languages/browse_thread/thread/af8838607b60cc0b/e7f3247409b57f19?lnk=gst&q=600mb#e7f3247409b57f19

I'm not going to make a fuss about them, my advice is to simply try both languages out and don't dismiss either due to nonsense reports.

Marcus

huxili,

After reading your report I wonder if Groovy is ready for anything, enterprise or not.

(Note - I am not against Groovy as a language per se. I have followed it ever since James Strachan came up with the idea)

huxili

The following article shows also Groovy is not ready for
entreprise application as well:
http://www.huxili.com/reports/ID000188</p>
It has serious design problem!