Getting off the Grails and Groovy Train
Previously, I wrote that Groovy and Grails are too risky to use, and this idea is now supported by G2One agreeing to be acquired by SpringSource. The backing of a common venture company for G2One and SpringSource probably facilitated this acquisition. Considering that SpringSource publicly praised MySQL as having a good business model, SpringSource may add additional restrictions to its offerings just like MySQL. Ext is another company that endorsed the MySQL model and ultimately followed the same path. Both companies spout quid pro quo often when it benefits them and sometimes refuse to give straight answers to simple questions. Will SpringSource pull an Ext and make the switch at a minor release after most Spring users convert their code over to Spring 3?
Even if the terms of use for Groovy and Grails do not immediately change, Grails will not support any fork of Spring Framework in the future. The FAQ indicates that Grails may use the same maintenance policy - apparently meaning limited free minor releases - as Spring Framework. The venture capitalists behind SpringSource will probably not tolerate Groovy and Grails making a lot less in returns than Spring Framework indefinitely, especially as all venture-funded companies are tightening their operations. This suggests additional restrictions, license change (an FAQ is not legally binding), or cancellation for Groovy and Grails down the track.
So if Groovy and Grails are no longer attractive options for some Java developers, what other choices are there? Given the massive performance issues of Groovy and Grails, Scala and Lift augmented with something like JavaRebel could be a better solution since Scala may actually run faster than Java on the JVM. JRuby on Rails and Django on Jython are other options. If you have to learn a new language anyway to use the next generation JVM frameworks, it seems better to stick with overseer organizations that are more trustworthy and less controversial.
If you really must stay with a Spring Framework stack, it might be safer to use Spring Framework with annotations as a substitute for Grails. There are many established examples like AppFuse that you can use to get you started. If you are only using Spring Framework for dependency injection, transactions, and maybe AOP, it should not be too hard to migrate to another solution like Guice. Considering how quickly Free Spring (formerly freespring.org) was organized, Spring Framework probably has a 100% chance to be forked successfully if necessary. Right after the Free Spring announcement, SpringSource may have realized the threat and therefore suddenly claimed to embrace community opinion. However, Groovy and Grails have much smaller communities and low chances of successful forks, so no threat of a Free Groovy/Grails there. As for using Groovy by itself, there are so many arguably better dynamic languages running on JVM that it makes little sense now to use Groovy unless you absolutely need the stronger Java integration.
November 12th, 2008 at 8:14 am
Can you clarify on what tests you base the assertion that Grails is slower than JRuby on Rails? In our testing Grails can serve close to 100 req/sec whilst JRuby on Rails could only manage half of that. I have no idea how Lift performs, but if you went for raw Spring MVC you would get around 120-140 request/sec.
If you wish to leave the platform due to your other concerns I have no problem with that, however please get your facts straight before spreading FUD.
November 12th, 2008 at 9:39 am
I was going by the performance of JRuby compared to Groovy since it is much easier to objectively compare languages than frameworks and the dynamic language is likely the bottleneck in these two frameworks. This is the first search result from Google: jruby groovy performance.
http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
For each language, these are the best numbers provided in microseconds per iteration.
Java: 1.6
JRuby: 80
Groovy: 104
I clarified the original statement.
November 12th, 2008 at 12:59 pm
Groovy 1.5 is indeed slightly slower than JRuby, however the upcoming Groovy 1.6 release actually reverses that in performs better in many benchmarks, see:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=groovy&lang2=jruby
As for not comparing frameworks, you have to do framework comparisons when making statements that compare the frameworks. Currently, Grails is built on Spring and Hibernate which gives it a significant performance advantage over JRuby on Rails even before Groovy 1.6 hits the streets.
Once Groovy 1.6 comes out expect those numbers to widen even further.
November 12th, 2008 at 4:14 pm
The Groovy version in that test is 1.6-beta-1 JVM: 1.6.0_03.
The Web applications that I have been working on recently are usually business logic intensive and not simple CRUD applications. Therefore, the language at the business tier matters a lot to me and I do not like the complexity of optimizing the bottleneck areas with a different language. GSP of the Grails presentation tier seems to get many performance complaints, and it uses Groovy heavily. Since I try to minimize the work done at the persistence tier to improve scalability, any potential CRUD performance advantages that Grails may offer there are less relevant for me.
I really have not seen formal and independent (not from one of the vendors) comparison of these frameworks, so for my needs the simple comparison based on the dynamic languages is sufficient. Both currently seem to be too slow for my taste. My requirements may not be typical, so my assessment may not be applicable to everyone.
November 13th, 2008 at 5:38 am
Ignoring the fact that most benchmarks are inherently flawed, what you’re saying is you’re going to take the word of a single isolate benchmark over a suite of benchmarks in the shootout AND you’re going to ignore framework performance. Using this rather odd logic you declare that JRuby on Rails is more performant than Grails. Doesn’t make much sense to me.
As for GSP, JRuby on Rails uses RHTML which is written in Ruby, so again it doesn’t make much sense that you state this a disadvantage of Grails. At least in Grails you can choose to use JSP if you’re not happy with the performance of GSP. Just like you can easily choose to use Spring beans written in Java in Grails for business tier logic if you feel its performance critical.
Also, I think before passing judgement you should consider performance vs scalability. They are 2 completely different things. Grails runs sky.com (as well as many other big sites) which receives 140million visitors a month with little issue proving it can scale.
Ultimately if you feel you don’t want to use Grails because you don’t like SpringSource then no, nobody is going to change your mind. However, as I said refrain from spreading FUD without obtaining the facts first.
November 13th, 2008 at 8:34 am
I clarified my statement as requested to state my method of evaluation (however flawed you may think it is) and you stated yours, so I was a little baffled as to why you are still on the offensive. Groovy/Grails and JRuby/Rails apparently have a history and I really do not want to get involved with any feud between these two sides. Even though there are other benchmarks where JRuby had lower iteration time, I removed any mention of JRuby/Rails performance relative to Groovy/Grails from the original blog so we can both get back to actual paying work.
If it makes you feel better, I will recommend Java instead
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=groovy&lang2=java
or Scala
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=groovy&lang2=scala
As for spreading FUD, by definition it is a tactic used in sales, marketing, and public relations. I could not care less which solution is more popular, since I do not plan to use either one anytime soon due to personal concerns about performance and memory usage. I never claimed to know more than the people that created one of those languages or frameworks. Individual and organization that actually spread FUD would probably not allow rebuttal on their Web sites.
You may wish to follow your own advice that you as a Groovy developer should not be commenting on JRuby as it reflects badly on you.
http://graemerocher.blogspot.com/2007/05/lone-ramblings-of-jruby-developer-in.html
November 14th, 2008 at 1:39 am
Very good, I am glad you have seen the error in your ways ;-)
I’m quite happy for you to compare statically typed language performance with dynamically typed languages like Ruby and Groovy. There are known differences between the two and the advantage of statically typed languages is clear.
As for the post you linked to, it was actually Ola expressing negativity towards Groovy. I never said anything negative about Groovy in the content of the post. What I do enjoy doing is at least trying to eliminate misconceptions that are spread about Groovy by certain individuals.
November 19th, 2008 at 5:12 am
I disagree with many of the responses above, but will move on and close the thread since the link spammers have found it already.