The award-winning software development partner recognized for innovative employee engagement measures
Ruby on Rails has generated significant buzz within the industry. However, for a large number of our clients this represents an unusual challenge because Ruby and Rails don’t necessarily integrate well with their significant existing investments in Java code/frameworks and they require new skill sets and training for their existing staff.
You are watching: Groovy on grails vs ruby on rails
Groovy and Grails have emerged as competitors to Ruby and Rails that tightly embrace the Java language and platform. For example, while Grails copies many ideas from Rails, it does so by leveraging existing frameworks such as Spring and Hibernate to achieve this.
It’s worth noting that from a deployment perspective, both Ruby on Rails (more specifically JRuby on Rails) and Groovy/Grails can be deployed as WAR files in a JDK 1.4 container. So neither approach requires radical changes to the underlying deployment and operations environment. But it’s in the development area where these frameworks differ.
This article is an attempt to explore the capabilities of both languages and frameworks and compare and contrast their approaches to problems. And while bias is unavoidable, I’ll at least try to separate the factual information from my own biased conclusions.
NOTE: Additional Rails and Grails competitors outside the scope of this document include:
Ruby vs Groovy
RubyandGroovyare both dynamic languages. The primary focus of this section is to compare the language level and standard library features and capabilities. However, some references to the additional language specific frameworks will be unavoidable since they are sometimes the best demonstrations of the capabilities of each language.
One thing that I will keep out of this section are specific comparisons between the Rails and Grails frameworks, since I will devote another entire section to that comparison later.
Rubywas created in 1993 and is a reflective, dynamic, object-oriented programming language. It combines syntax inspired by Perl with Smalltalk-like object-oriented features, and also shares some features with Python, Lisp, Dylan, and CLU. Ruby is a single-pass interpreted language. Its official implementation is free software written in C.
object-orientedfour levels of variable scope: global, class, instance, and localthree class/instance variable visibilities: public, protected, and privateexception handlingiterators and closures (based on passing blocks of code)native, Perl-like regular expressions at the language leveloperator overloadingautomatic garbage collectinghighly portableintrospection, reflection and metaprogramminglarge standard librarysupports dependency injection (via external frameworks)supports Object runtime alteration<8>supports mixins (at class/static level via extend, at instance level via include)continuations and generators (examples in RubyGarden: continuations and generators)can run on the Java JVM (via JRuby)default MRI runtime features (not running on JVM):cooperative multi-threading on all platforms using Green threadsDLL/shared library dynamic loading on most platforms
Ruby currently lacks full support for Unicode, though it has partial support for UTF-8.
Groovywas created in 2003 and is a dynamic language that was the first, and currently only, JSR approved language (JSR-241) other than Java for the JVM. Though to be fair, other languages like Ruby fall under the umbrella ofJSR-223Scripting for the Java Platform, and hundreds of other languages can compile to bytecode and run on the JVM.
Groovy includes features found in Python, Ruby, and Smalltalk, but uses syntax similar to the Java programming language. Groovy’s similarities to Java and reliance on the JDK set it apart from these other dynamic languages and enable it to achieve a level of integration with Java that has yet to be reached in other languages.
most valid Java code is also valid Groovy codeobject-orientedfour levels of variable scope: binding (global), class, instance, and localthree class/instance variable visibilities: public, protected, and private (java’s default package access is not supported)exception handling (unlike Java, catching any exception type is optional)iterators and closures (based on passing blocks of code)native, Perl-like regular expressions at the language leveloperator overloadingautomatic garbage collectinghighly portableDLL/shared library dynamic loading on most platformsintrospection, reflection and metaprogramminglarge standard librarysupports dependency injection (via external frameworks)supports Object runtime alterationsupports mixins (at the class and instance level via Categories)static typing and dynamic typing (i.e. static typing is optional)native syntax for lists, maps, and regular expressions (different than Java)language level concurrency support (can be implemented via native or green threads depending on JVM)
no support for continuationsno support for generators (I’d like to research this further–it appears you can kludge it, but can’t truly support it without continuations)Groovy uses a different syntax than Java forforloops. As such, a lot of valid Java code that would otherwise also be valid Groovy code ends up with compilation errors and must either remain Java or be ported to Groovy’s syntax.Groovy has the quirk of being able to optionally use parenthesis for method calls with parameters, but requiring them for methods with no parameters (unless you use the hack of naming the method getMethod to trick Groovy into thinking it’s a property). (This quirk is actually a result of Groovy’s tight embracing of the existing JavaBean’s standard.)
Ruby vs Groovy Comparisons
Stack traces are long and illegible. The reason for this is that making a dynamic call in Groovy adds an average of somewhere between 6 and 12 calls to the stack. So what might be a reasonable 20 line stack trace in “normal” Java ends up as a 200+ line stack trace in Groovy. And what’s worse, you probably don’t care about the majority of the stack (it would be nice if there was a simple way to filter out that crud or at least hide it). Here’s an example from a little script I wrote to call a web service (which btw is as simple as this in Groovy):