Should we introduce Grails at Gale?

[Erik Przekop]

I like the idea of using a dynamic language and a *good* framework for
our projects. I think that either Groovy / Grails or Ruby / Rails fit
the bill. Grails is a better fit, though, since it packages as a .war
and you can call groovy or java from the same project.

If you haven't tried it, I strongly suggest it. STS is probably the
best IDE for it, though Gedit (or Textmate, or whatever) with a
terminal window works pretty well too!

What does everyone else think? How/when could we introduce it at
work? When *should* we?

[Duane May]

I have been playing around with Groovy/Grails the last few months. Much like Ruby/Rails, the convention over configuration makes it super easy to get some quick prototypes up and running. It is also a strong choice when you have a domain model that you want to persist to a new database. 

However, I like the idea of Groovy/Grails since we already have the JVM on every machine, we wouldn't have to change any deployment models. We could gradually begin to implement it, since it runs in the same JVM, can interact with all of our existing code, and libraries. 

As for an IDE, I have tried Eclipse and installing the plugins from the eclipse marketplace but kept getting errors on installation. STS worked right out of the box. It occasionally gets confused if you create a new controller, add a plugin, change the bootstrap, or make major changes and the application server is running,  but for the most part a couple reloads of the page gets all the changes you made. 

The syntax can be almost Java like, but to really get the power from Groovy you should look for the Groovy ways of doing things. You can dynamically add methods to existing classes, or to all classes at once, which is how groovy made some of the existing Java interfaces better.

 

If you are interested in seeing it yourself, I recommend you download Grails and STS and follow along as Jeff Brown builds Twitter in 90 minutes using Grails... http://www.youtube.com/watch?v=8d1hp8n1stA

[AimmeKeener]

I think it is a great idea to bring this in. A comment that still
pops into
my head frequently is that we didn't use JMS for audit logging because
we
didn't have any experience with JMS. Even though JMS had been around
(and
used) for years, we felt like we needed internal experience.

For the answer to when, I think that we try to find an internal
problem that
we are trying to solve and implement a Grails solutions. I would run
it as
a project in one of the management/practices groups. Of course, there
is
also the option of introducing it in code randori or craft day or
after
hours events. But, my concern is that those events would not maintain
focus
and maintain a consistent pace to ensure the language is introduced
and the
problem is solved. (Too much stopping and starting and transient
participation.) That being said, they (code randori or craft day or
after
hours events) are great places to introduce Grails and get people
thinking
about problems that they might be able to solve faster/better with
Grails.

Concerning potential problems (all off the top of head, which mean
that they
are probably real bonehead ideas :) ):

- Something for the concepts team to help set up concept
applications/products?
- Set up an application to help people understand how they are
progressing on the developer curriculum? Or, a way to track it
themselves?
- Create an application that pulls in Hudson, Sonar, dashboard
reporting,
and the agile charts into one location?

[Karen]

Applications to work on? Well, we could use a new time-tracking
system.....

[Tim Taylor]

Short version:

JRuby or Scala, not Groovy. For deployment, Rails has warbler, Scala
has 'mvn package'.


Long version:

I built a project in Groovy at ePrize. I haven't built anything in
Ruby or Scala as substantial as that Groovy project; take my opinion
for what it's worth.

When finished the Groovy project I found myself disliking Groovy. It
reminds me of perl, a hodgepodge of features layered on top of each
other, lacking a sense of cohesion or good language design. It's a
middle of the road solution, which seems pragmatic initially, but ends
up feeling mediocre after using it. In my beginning forays I find both
Ruby and Scala preferable to Groovy.

James Strachan, Groovy co-creator, recommends Scala:

"I can honestly say if someone had shown me the Programming in Scala
book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd
probably have never created Groovy."
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html

He continues to blog about Scala.

Groovy has the drawback of a dynamically typed language in terms of
tooling, but doesn't feel like the best such language. Scala
eliminates a lot of the boilerplate in Java and has good tooling
support as of 2011 (refactoring, code navigation, code assist in all
major Java IDEs).

For deploying, JRuby has the Warbler gem for packaging up a Rails app
as a WAR file. For Scala it's 'mvn package' assuming we've built on
top of the Servlet API.

[Duane May]

Tim, Was your project using Groovy alone or Grails over Groovy? 

I do have concerns on performance, as some of the things I've done in Groovy seems to be a bit slower then equivalent code in other languages. I guess you should expect some decrease in performance from a dynamically typed language.

Scala has the advantage that it is type safe, but doesn't have the overhead of having to declare the types. I haven't used Scala, but it seems okay from a few times I have looked at it. 

In looking for Scales (Rails/Grails equivalent), it looks like Lift is the most popular web framework for Scala? 

As much as I could gather from the Amazon preview of the Lift book, it looks painful. 

Has anyone used Lift with Scala?  

[Janet Li]

I have working experiences on both Groovy and JMS (Weblogic JMS, JBoss
JMS). We had used Groovy to process text/xml files at run time on the
java web server. Because of the way Groovy is created, we can drop any
Groovy script onto the java web server at run time to process any
customized files. It worked great in that way. But before we can use
Groovy/Grails for any web apps in production, we need to dig deeper on
scalability, extensibility, and etc. To me, a dynamically typed
language may be suitable for prototyping or small sized applications
however they may not be mature enough for large sized applications.
Just my 2 cents.

[Tim Taylor]

The Groovy project I did was just Groovy, no Grails. Performance was
slow compared to Java, but we ran a lot of Perl apps so it was
acceptable, at least for getting started. The plan was to convert
hotspots to plain Java if necessary, but didn't become necessary while
I was there.

I reacted to Erik's question as "is Grails the single next framework
to try?" If we can run a few experiments with different frameworks,
then we absolutely should give Grails a try. If we only have room to
try one, I'll still lobby against Grails, but I'm happy that we're
looking at alternatives.

[Erik Przekop]

That surprises me - I thought that a JVM language was a JVM language,
and that they all got the benefits of hotspot optimization. Looks
like I was wrong, based on your experience. I also found this blog
post: http://www.christianschenk.org/blog/performance-comparison-between-groovy-and-java/

The author says that Java is 3 orders of magnitude faster across
almost all tests... but that he things that performance is very
similar across code that actually *does* something, rather than an
artificial test. Worth a read, anyway.