Live data from Hacker News

The Groovy project is looking for a new home

glaforge.appspot.com

11–20 of 72 posts

Re: The Groovy project is looking for a new home

#12
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.

Re: The Groovy project is looking for a new home

#13
post #12

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 toolin…

As someone who has done a lot in both frameworks, I have found Grails to be more mature from an enterprise standpoint, and the tooling support is outstanding. IMHO, it's a lot easier to track down what is happening where in Grails as opposed to Rails.

Re: The Groovy project is looking for a new home

#14
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.

Re: The Groovy project is looking for a new home

#15

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.

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:…

On the contrary, Ruby and it's community feels off-topic. I also question that functional programming is Groovy's prime feature or use case.

Re: The Groovy project is looking for a new home

#16
post #5

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,…

I really like to know why you were downvoted, because I made the same observations you did and basically came to the same conclusion. I'd add the really bad IDE support. I've met some developers that said the only thing that kept them from leaving Groovy was that Grails and Spock are really great and worth the trouble. Other than that I see Groovy's future more as a glue language and as a language for tools. Which I'd find very unfortunate because I like Groovy's simplicity & flexibility as a JVM language.

Re: The Groovy project is looking for a new home

#17
post #5

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,…

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.

Re: The Groovy project is looking for a new home

#18
post #16
post #5

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,…

I really like to know why you were downvoted, because I made the same observations you did and basically came to the same conclusion. I'd add the really bad IDE support. I've met some developers that said the only thing that kept them from leaving Groovy was that Grails and Spock are really great and worth the trouble. Other than that I see Groovy's future more as a glue language and as a language for tools. Which I'…

Groovy IDE support is now really good in the groovy on grails tool suite, which is the main thing that I fear will disappear with this decision.

Most refactors, pretty good line-by-line debugging, etc.

Edit: GGTS is A spring-specific eclipse distribution..

Re: The Groovy project is looking for a new home

#19
post #11
post #9

Linked site over quota. Cached: http://webcache.googleusercontent.com/search?q=cache:tVxs2fJ...

Coral cache: http://glaforge.appspot.com.nyud.net/article/the-groovy-proj...

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.

Re: The Groovy project is looking for a new home

#20
post #16

Earlier quoted context omitted.

I really like to know why you were downvoted, because I made the same observations you did and basically came to the same conclusion. I'd add the really bad IDE support. I've met some developers that said the only thing that kept them from leaving Groovy was that Grails and Spock are really great and worth the trouble. Other than that I see Groovy's future more as a glue language and as a language for tools. Which I'…

Groovy IDE support is now really good in the groovy on grails tool suite, which is the main thing that I fear will disappear with this decision. Most refactors, pretty good line-by-line debugging, etc. Edit: GGTS is A spring-specific eclipse distribution..

It's also extremely good in Intellij (at least, in Ultimate...which is what I'm using daily).
Post reply on HN