I know and use both Ruby/Rails and Groovy/Grails and wanted to debunk a myth here:<p>"Interest in Grails/Groovy is diminishing" - I won't comment on trends but there is still a large, active user base and community<p>I won't list the benefits of Ruby/Rails over Groovy/Grails because I will assume the audience here is familiar with Ruby/Rails.<p>Specifically here are some benefits of Groovy over Ruby:<p><pre><code> - Very good JVM tooling and integration
- Familiar (Java)
- Developer friendly (Ruby has a number of syntax warts, e.g. elvis operator, null safe operator - just to start) syntax
- Optional static compilation
- Optional typing
</code></pre>
and Grails over Rails:<p><pre><code> - Performance - take a look at techempower benchmarks http://www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=query
- Spring integration - having Spring built in is often useful in an enterprise context where existing Spring use exists
- Typing is nice if you like that (Mentioned above)
</code></pre>
When I need to decide between using Grails and Rails, it usually comes down to developer convenience vs performance. I am asking myself do I want to give up a lot of performance (with Grails) for a little more developer conveniences (with Rails)? Sometimes the answer is yes, sometimes no.
Understanding this decision requires understanding Pivotal more broadly. EMC (which owns VMWare, which owned Spring) bought Pivotal Labs (primarily a Ruby consultancy) and used the brand for a new spinoff company (Pivotal Software, Inc). That spinoff company received as its founding endowment a hodge-podge of enterprise software technologies they had acquired over the years - Spring, RabbitMQ, CloudFoundry, Greenplum - and the consultancy, which is still called Pivotal Labs. For the most part they put the Ruby consultancy people in charge.<p>Even though Pivotal Software is an amalgam, Pivotal received most of its culture from Pivotal Labs. To the extent that you can anthropomorphize a corporation, it really, <i>really</i> likes Ruby. Because of CF, it's warming up to Go fast. Spring is too big and important to neglect. But it's hard to see how Groovy/Grails fit into the big picture. It's not in vogue with the top decisionmakers and it's not critical to the business - it's just something that tagged along with Spring. I doubt anyone has any idea what to do with it.
Props to what Guillaume has accomplished, but the original raison d'etre for Groovy existing has largely been supplanted by the rise of JRuby and Scala. When Groovy was initially developed JRuby was (arguably) not yet mature enough for production, so developers wanting to use Rails under the JVM were basically out of luck. Grails was developed in response to this need.<p>Now that JRuby is more mature (and, as of today, the only one of the two with official sponsorship) the need for Grails is greatly diminished. The only other major development effort that utilizes Groovy is Gradle, and that has been met with mixed levels of enthusiasm. Add to this that Java itself has made some strides with adding functional(-ish) features to the language, and the benefits that Groovy brings to the table are not as pronounced as they once were.<p>And for devs who are wanting something that is more purely functional there is Scala.<p>Given this I'm not particularly surprised to see Pivotal's decision here. Groovy has always struggled for more widespread relevance, and while it is sad to see this happen, it's also far from unreasonable.
Groovy is a very flexible language with an elegant and approachable syntax.<p>It provides fantastic support for concurrency with gpars.<p>It provides the ability to write static or dynamic code.<p>It integrates seamlessly with Java.<p>I feel groovy has created it's own space in the ecosystem, continues to grow and has a bright future.
I really wish we had the money to hire all the Groovy / Grails developers here. I'd do it in a heartbeat. Almost all of our products are built primarily with Groovy + Grails, and I'd hate to see the project(s) lose substantial momentum.<p>OTOH, I expect both projects to remain alive, even without corporate backing, although perhaps not moving quite as quickly (which would still be a loss).
Love Groovy's static+dynamic typing. I developed HiveMind (www.crudzilla.com) and the IDE backend is written entirely in Groovy primarily because I am a Java developer and could use Groovy without having to learn a new syntax.
Linked site over quota. Cached:<p><a href="http://webcache.googleusercontent.com/search?q=cache:tVxs2fJEi80J:glaforge.appspot.com/article/the-groovy-project-is-looking-for-a-new-home+&cd=1&hl=en&ct=clnk&gl=us" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:tVxs2fJ...</a>
And just a couple of hours ago I was thinking "How come I haven't seen any articles on Groovy on the front page in a while?".<p>Seems its hype has been eclipsed by Clojure and Scala.
Groovy has one of the nicest approaches to compile time metaprogramming (apart from Lisp, of course).<p>I often wish it had gained more momentum before Clojure and Scala showed up.<p>The Java interoperation is much, much cleaner than in Jython or JRuby due to Groovy being a first class JVM language.
Doesn't Google depend on them now, due to Gradle being a part of the official Android toolchain? Seems like they should be interested in doing this.
I hope they can find a model like how Django (Python) has its own foundation to support it. With Gradle being defacto build tool for Android ecosystem and companies like Netflix using it, it feels like they would have no problem with finding a new home/raising-fund for future.<p>I have been using Groovy and Grails for less than a year now and love it so far.
I like Groovy. The language has the ability to made some very, very nice DSLs (almost english-like).<p>But the buzz around Groovy has diminished. There's only so much room for the already crowded JVM ecosystem. It's great to have choice, but there's only X number of developers, X number of companies that can sponsor, X number of users that build a community.<p>I'd like to see a language like Groovy, but with some of the semantics of Clojure, and some optional typing. Maybe it's time for a reboot of the language.