
The Groovy project is looking for a new home - varmais
http://glaforge.appspot.com/article/the-groovy-project-is-looking-for-a-new-home
======
bjfish
I know and use both Ruby/Rails and Groovy/Grails and wanted to debunk a myth
here:

"Interest in Grails/Groovy is diminishing" \- I won't comment on trends but
there is still a large, active user base and community

I won't list the benefits of Ruby/Rails over Groovy/Grails because I will
assume the audience here is familiar with Ruby/Rails.

Specifically here are some benefits of Groovy over Ruby:

    
    
      - 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
    

and Grails over Rails:

    
    
      - 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)
    

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.

~~~
mbell
I've also used both languages a fair bit, but I've never used Grails (although
I've played with it).

Couple things to add to the pros/cons:

> Developer friendly (Ruby has a number of syntax warts, e.g. elvis operator,
> null safe operator - just to start) syntax

I would love to see the elvis operator and the null safe operator in Ruby, but
I'd also like to see blocks in Groovy.

An addition to the pros of Groovy:

Interacts extremely well with existing Java code. While you can call into Java
from JRuby, it's no where near as clean to interoperate with Java in the same
code base. In the past I've loved Groovy because I could use it very cleanly
inside a codebase that had a lot of Java, e.g. use Groovy to write controllers
or data munging code but use Java for most other things.

~~~
sytse
Isn't the elvis operator || in ruby? see
[http://stackoverflow.com/a/7816041/613240](http://stackoverflow.com/a/7816041/613240)

~~~
bjfish
Yes, but I think that syntax is a little ugly, see
[https://news.ycombinator.com/item?id=8916893](https://news.ycombinator.com/item?id=8916893)

------
stickfigure
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.

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, _really_ 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.

~~~
vorg
You'd also need to understand that not all full-time Groovy and Grails
developers make equal contributions. Funding the 2 technical workers on Groovy
might make sense for a business, but due to ownership problems related to the
brand, codebase, support, channels, and what not, disentangling these 2
workers from the whole mess is a legal nightmare. Perhaps there's something
similar with Grails, but I don't know much about that one. Pivotal obviously
decided simply terminating funding was more profitable than trying to split
off a separate business and sell it all to someone else.

------
revscat
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.

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.

And for devs who are wanting something that is more purely functional there is
Scala.

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.

~~~
cowardlydragon
NOPE.

Ruby doesn't offer one of Groovy's killer features: optional static typing.

And Scala... far too alien and complex. There was some talk out there by one
of the original Scala dudes talking about how there are something like 30
different fundamental types in Scala.

Groovy offers the most accessible functional programming paradigms to Java
programmers. It is a sweet spot.

~~~
revscat
Well, I actually like Groovy, and was trying to keep my personal opinion out
of my original post. The fact remains, though, that whatever strengths Groovy
has as a language it has struggled to gain significant traction.

~~~
coldtea
> _The fact remains, though, that whatever strengths Groovy has as a language
> it has struggled to gain significant traction_

Compared to what? JRuby? Groovy's adoption, from the number's I've seen, walks
all over JRuby's.

It's just that the Java world is not fashionable (besides say Clojure) and you
don't often hear from the people who use Groovy in their enterprise projects,
whereas 10 startups using the language-du-jour can create the impression that
it's the hot shit on HN.

~~~
pjmlp
No, but you do get presentations at local JUG and those have been pretty empty
of Groovy content in the last years.

~~~
coldtea
I think people that go to JUGs and people that do enterprise development are
entirely different species...

~~~
lostcolony
That was not at -all- my experience when I went to one in Atlanta. I and one
other guy were the only ones in t-shirts; every single other person was in
polo and khakis at least, with quite a few dress shirts and suits. Pretty sure
it was mostly dominated by enterprise. Admittedly, that was my one and only
experience with one; it was sufficiently enterprise-y and uninteresting for me
that I never went back.

------
derpshmerp
Groovy is a very flexible language with an elegant and approachable syntax.

It provides fantastic support for concurrency with gpars.

It provides the ability to write static or dynamic code.

It integrates seamlessly with Java.

I feel groovy has created it's own space in the ecosystem, continues to grow
and has a bright future.

~~~
laichzeit0
The concurrency support with gpars is a really killer feature. I'd urge
everyone to take at least just take a look at it. Extremely easy and made very
"natural" with Groovy syntax. Yeah you can do concurrency with about every
other language, etc. but this is within a JVM context.

------
mindcrime
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.

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).

------
Edmond
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.

~~~
pjmlp
Interesting. Specially that you decided to make use of JSR-223.

Good luck for the business.

------
bonsai80
Linked site over quota. Cached:

[http://webcache.googleusercontent.com/search?q=cache:tVxs2fJ...](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)

~~~
j_s
Coral cache: [http://glaforge.appspot.com.nyud.net/article/the-groovy-
proj...](http://glaforge.appspot.com.nyud.net/article/the-groovy-project-is-
looking-for-a-new-home)

~~~
mdaniel
I almost wish Coral-caching links was the default, given that making the
frontpage can be a real bad thing for smaller sites.

Also, if the "portless" version doesn't work for anyone, I've experienced that
adding :8080 and :8090 can have better luck. I am unaware of the difference
between the two ports.

~~~
fletchowns
Kinda robs people of ad impressions though

------
vezzy-fnord
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?".

Seems its hype has been eclipsed by Clojure and Scala.

~~~
lisa_henderson
I think the hype around Groovy was at its peak when folks were the most
interested in having something like Ruby running on the JVM, and jRuby did not
yet seem like a viable option. But even the hype for classic MRI Ruby has been
waning, as developers look to do more with concurrency, and they discover
dynamic everything-is-mutable languages have limits when it comes to
concurrency. See Tony Arcieri's article "2012: The Year Rubyists Learned to
Stop Worrying and Love Threads (or: What Multithreaded Ruby Needs to Be
Successful)" and where he wrote:

"I’m talking about at Dr. Nic’s talk at RubyConf 2011, a little more than a
year ago. Dr. Nic had a fairly simple message: when performance matters, build
multithreaded programs on JRuby (also: stop using EventMachine). Now granted
he was working the company that was subsidizing JRuby development at the time,
but I didn’t, and I for one strongly agreed with him. Not many other people in
the room did. The talk seemed to be met with a lot of incredulity."

So even among Rubyists, there has been growing interest in Ruby beyond the
MRI, and if that is happening in the land of Ruby, then the argument for
Groovy is that much weaker.

At the same time, the growing interest in dealing with concurrency certainly
helped increase interest in Scala and Clojure, and furthermore, functional
programming in general. If you are a developer who wants to harness the power
of concurrency for greater speed, Scala and (especially) Clojure are full of
interesting ideas for how to do that. Groovy, meanwhile, feels off-topic.

~~~
cowardlydragon
Again, just because Groovy rhymes with Ruby doesn't mean that is its sole
purpose.

Ruby doesn't have optional strong typing, which is critical to Groovy's
bridging of Java and Ruby.

The optional strong typing enables a host of significant advantages, from code
readability and assertions to IDE tooling/autocomplete ease... better API
design... and many other things.

------
_pmf_
Groovy has one of the nicest approaches to compile time metaprogramming (apart
from Lisp, of course).

I often wish it had gained more momentum before Clojure and Scala showed up.

The Java interoperation is much, much cleaner than in Jython or JRuby due to
Groovy being a first class JVM language.

------
tree_of_item
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.

~~~
cowardlydragon
It might be for the best. I heard that the VMWare people are a bit scuzzy and
unethical, such as slapping legal threats on authors to take over their github
projects. Of course that was from what I _thought_ was a drama queen ex-groovy
committer, but now he looks much more sane.

Pivotal is trying to push vert.x now, which I think is a node.js for JVM type
of thing.

Since they never did make an awesome configure-spring-with-groovy conversion,
I guess this won't be too painful of a split.

Groovy was the #1 JVM language besides Java for quite a while, I think it
still is despite Clojure/Scala hype. It was before pivotal took it on, and it
probably will be fine.

It's feature set is actually fairly stable. It doesn't need to do Java
lambdas, since it has its own, so no major Java cross compatibilities to port
from Java8.

~~~
blktiger
I was disappointed that Spring decided to move away from the groovy config
option. I thought of all the different configuration options that one looked
the most elegant. I really dislike the current "Java" config fad they are
going through. It looks like Java, but it's not really Java, it's a DSL for
Spring configuration.

------
ireadzalot
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.

I have been using Groovy and Grails for less than a year now and love it so
far.

------
mikerichards
I like Groovy. The language has the ability to made some very, very nice DSLs
(almost english-like).

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.

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.

