The Groovy project is looking for a new home(glaforge.appspot.com)
glaforge.appspot.com
The Groovy project is looking for a new home
http://glaforge.appspot.com/article/the-groovy-project-is-looking-for-a-new-home
71 comments
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.
> IMHO, it's a lot easier to track down what is happening where in Grails as opposed to Rails.
Do you have any examples here? I can't think of a time when I've had to hunt long to figure out where things are happening in Rails.
Do you have any examples here? I can't think of a time when I've had to hunt long to figure out where things are happening in Rails.
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.
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.
> but I'd also like to see blocks in Groovy
Groovy allows passing a closure to a method with signature (where p3 is a callable)
Groovy allows passing a closure to a method with signature (where p3 is a callable)
a(p1, p2, p3)
a(some_val, some_val){ closure content }
Isn't the elvis operator || in ruby?
see http://stackoverflow.com/a/7816041/613240
Yes, but I think that syntax is a little ugly, see https://news.ycombinator.com/item?id=8916893
Sorry to turn this into a framework war, but as someone who made the move from Groovy/Grails to Scala/Play Framework, I can't imagine ever going back. Or in other words, my answer to "A or B?" is "C".
My experience with Scala Play was very different. Scala is an interminably difficult language fraught with pitfalls.
It's much easier to write unreadable Scala code than Groovy.
It's much easier to write unreadable Scala code than Groovy.
Agreed. Groovy is in my opinion absolutely the nicest and friendliest language to read or write. Scala has some really cool features that I would love to see in other languages, but it also has a tendency to become somewhat unreadable and is a lot harder to get into when you're new to it.
Groovy is gaining popularity among scientists and researchers because of it's ease of use and performance.
Really? I've been using it but I feel pretty lonely. I ended up creating my own Groovy based version of R / pandas data frames because there is simply nothing out there. I'm curious in what ways you're seeing it used.
I haven't used Groovy much, so I may be completely missing something here, but how is the elvis operator different from a simple guard in Ruby?
Based on the docs for elvis, it looks like
Further, the null-safe operator seems to be the same as #try in Rails and overuse of either is probably a bit of a smell that you might be violating Tell Don't Ask
Based on the docs for elvis, it looks like
potentiallyFalsyValue ?: safeDefault
potentially_falsy_value || safe_default
Further, the null-safe operator seems to be the same as #try in Rails and overuse of either is probably a bit of a smell that you might be violating Tell Don't Ask
It's subtle, but I think the difference is that in ruby when potentially_falsy_value is false you will get the safeDefault. But with ?: you would get the potentiallyFalsyValue as false. The only time you get safeDefault is when potentiallyFalsyValue is nil/null
The docs seem to state otherwise
One instance of where this is handy is for
returning a 'sensible default' value if an
expression resolves to false or null
Yes, I see || as a wart or crufty. Think about the type signature of || in ruby:
If || is used more frequently as a logical operator returning true(1) or false(0) to test logical or (not to be used for assignment), why overload this operator?
Having a separate operator like ?: better shows the intention of the usage. It also resembles the ternary function which has similar functionality.
<Type 1 or Type2> ||(Type1 arg1, Type2 arg2)
boolean ||(arg1, arg2)If || is used more frequently as a logical operator returning true(1) or false(0) to test logical or (not to be used for assignment), why overload this operator?
Having a separate operator like ?: better shows the intention of the usage. It also resembles the ternary function which has similar functionality.
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.
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.
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.
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.
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.
> Given this I'm not particularly surprised to see Pivotal's decision here
Pivotal's decision is likely based not only on what you see, but on what else they see but you can't. They can see trends and revenues before the rest of us can, like former SpringSource CEO Rod Johnson who jumped ship over to Scala.
These are some concerns with Groovy I've blogged and commented about a lot over the past few years:
* the failure of static typing to take hold in any way. Groovy's a dynamically-typed scripting language for Grails, Gradle build scripts, and Java class manipulation. Virtually no-one uses Groovy to build systems, and even Gradle's codebase is virtually all Java. Groovy's a good scripting language for Java, like bash for Linux, and the project management should have stuck to their knitting and made it better instead of diversifying into static typing and now Android.
* their obsession with popularity rankings. Tiobe, Stack Overflow, and Github are gamed. The download numbers are fabricated. This goes far beyond what other programming language communities get up to. A year ago Groovy was number #18 in Tiobe (Oct 2003) but now they're not even in the top 50, and in April 2011, Groovy dropped from #25 to #65 in a single month, all this because of someone manipulating search engine results for some short-term marketing.
* the constant fight for control over the product. The original post is to a person's personal blog instead of one on Codehaus or Pivotal. This started happening a year ago, when that person also started soliciting for subscribers to a personal weekly mailout instead of supporting the community mailing list. No-one knows who controls the new Groovy website being promoted. One of the 5 despots in the official Codehaus despotry is trying to take over. This has been going on for the entire lifetime of Groovy when its creator was pushed out.
* the lack of documentation or any language standard designed to make people dependent on consulting and conferences. In the Groovy 1.x days, they even appeared to be changing things to shake off other independent documentation efforts or addon software like Groovy++. When the present management took over, they kept the JSR standard inactive to deliberately prevent anyone building another implementation.
I'm only talking about what happened to Groovy after its creator James Strachan left the project, not before. As for Grails, I don't know much about it except that Groovy's direction seems to be dictated by it. And Gradle seems to be on course for dropping Groovy as their sole scripting language if you read between the lines on their website.
Pivotal's decision is likely based not only on what you see, but on what else they see but you can't. They can see trends and revenues before the rest of us can, like former SpringSource CEO Rod Johnson who jumped ship over to Scala.
These are some concerns with Groovy I've blogged and commented about a lot over the past few years:
* the failure of static typing to take hold in any way. Groovy's a dynamically-typed scripting language for Grails, Gradle build scripts, and Java class manipulation. Virtually no-one uses Groovy to build systems, and even Gradle's codebase is virtually all Java. Groovy's a good scripting language for Java, like bash for Linux, and the project management should have stuck to their knitting and made it better instead of diversifying into static typing and now Android.
* their obsession with popularity rankings. Tiobe, Stack Overflow, and Github are gamed. The download numbers are fabricated. This goes far beyond what other programming language communities get up to. A year ago Groovy was number #18 in Tiobe (Oct 2003) but now they're not even in the top 50, and in April 2011, Groovy dropped from #25 to #65 in a single month, all this because of someone manipulating search engine results for some short-term marketing.
* the constant fight for control over the product. The original post is to a person's personal blog instead of one on Codehaus or Pivotal. This started happening a year ago, when that person also started soliciting for subscribers to a personal weekly mailout instead of supporting the community mailing list. No-one knows who controls the new Groovy website being promoted. One of the 5 despots in the official Codehaus despotry is trying to take over. This has been going on for the entire lifetime of Groovy when its creator was pushed out.
* the lack of documentation or any language standard designed to make people dependent on consulting and conferences. In the Groovy 1.x days, they even appeared to be changing things to shake off other independent documentation efforts or addon software like Groovy++. When the present management took over, they kept the JSR standard inactive to deliberately prevent anyone building another implementation.
I'm only talking about what happened to Groovy after its creator James Strachan left the project, not before. As for Grails, I don't know much about it except that Groovy's direction seems to be dictated by it. And Gradle seems to be on course for dropping Groovy as their sole scripting language if you read between the lines on their website.
+1 - most of grails is also written in java, drives me crazy when trying to debug some of the day to day weirdness you get with grails..
It's good to get a view of whats going on within the community here, I've only ever seen it from the outside looking in.
That said I love groovy as a language. A friend and I wrote a fairly complicated currency breakdown algorithm (lots of corner cases and BigDecimals) once in groovy in about 3 hours, was about 40 lines of code. The production codebase was java so after porting it was something like 300+ lines of unintelligble masses of .divide() .multiply() .compareTo() and so on.
It's good to get a view of whats going on within the community here, I've only ever seen it from the outside looking in.
That said I love groovy as a language. A friend and I wrote a fairly complicated currency breakdown algorithm (lots of corner cases and BigDecimals) once in groovy in about 3 hours, was about 40 lines of code. The production codebase was java so after porting it was something like 300+ lines of unintelligble masses of .divide() .multiply() .compareTo() and so on.
If you're gonna trash talk Groovy, at least get your facts straight. Note: Static typing which has existed in Groovy forever.
Static typing (both type-checking and compilation) was added to Groovy for version 2.0 released in June 2012.
No, that is annotations that assists the compiler. In Groovy 1.X I could still write public List<MyObject> mylist = new ArrayList<MyObject>() and it would behave exactly as you would expect.
By static typing, I meant compile-time type checking, and statically-typed compilation. You describe run-time type checking in dynamically-typed compiled code which was in Groovy (without generics) from the beginning but makes the code run even slower than the already slow dynamically-typed compiled code without such run-time type checking. Run-time type checking with generics was added to Groovy from version 1.5.
Perhaps I should've used the expressions "compile-time ..." and "run-time ..." to be more accurate, but virtually everyone uses "statically-typed" and "dynamically-typed" in their place.
Perhaps I should've used the expressions "compile-time ..." and "run-time ..." to be more accurate, but virtually everyone uses "statically-typed" and "dynamically-typed" in their place.
Correct.
Actually the Groovy developers call it optional typing, not static typing. And it has always been confusing.
Still though, if you really really need static typing at compile time, Groovy never stopped you. You have always had the possibility to call Java code from Groovy and Groovy code from Java as Groovy compiles to valid Java byte code.
Actually the Groovy developers call it optional typing, not static typing. And it has always been confusing.
Still though, if you really really need static typing at compile time, Groovy never stopped you. You have always had the possibility to call Java code from Groovy and Groovy code from Java as Groovy compiles to valid Java byte code.
The other poster is right. That is typing, that is not static type checking.
You can write code like:
List<MyObject> mylist = new HashSet<Integer>() {{ add("string"); add(1L); }}
You will get groovy.lang.GroovyRuntimeException with constructor issues.
You can write code like:
List<MyObject> mylist = new HashSet<Integer>() {{ add("string"); add(1L); }}
You will get groovy.lang.GroovyRuntimeException with constructor issues.
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.
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.
I loathe the "it's to hard" argument. I understand it, and it always makes sense. But it's like a drug. So many organizations fall prey to refusing to adapt until it's too late.
That said, it sounds like Groovy is a great fit for your organization.
That said, it sounds like Groovy is a great fit for your organization.
Since my dabble with Groovy for a JSF framework back in 2009, I never really used it, except now that Google is forcing it on me.
From a few talks I have watched on the internet, it actually seems that Groovy is trying to adopt every language feature, like being lost while looking for new a direction kind of.
Kind of trying to stay relevant in a world of Scala, Clojure, Ceylon, Kotlin, js_ocaml, who knows what.
Maybe I am completly wrong, this was my impression after seeing recent videos.
From a few talks I have watched on the internet, it actually seems that Groovy is trying to adopt every language feature, like being lost while looking for new a direction kind of.
Kind of trying to stay relevant in a world of Scala, Clojure, Ceylon, Kotlin, js_ocaml, who knows what.
Maybe I am completly wrong, this was my impression after seeing recent videos.
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.
>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.
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.
No, but you do get presentations at local JUG and those have been pretty empty of Groovy content in the last years.
I think people that go to JUGs and people that do enterprise development are entirely different species...
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.
In Germany JUG are all about enterprise.
IME, the strengths were primarily that it was Java+. However, the Java-heavy organizations that might most benefit from it tended to also be the most averse to change. Changing "that much" for "only" incremental change wasn't worth the risk for risk-averse companies. The companies that weren't risk averse tended to try it, but also go outside the JVM altogether when appropriate. So... in a way it was too good at just being a more useful Java, but that wasn't enough for Java-heavy shops.
I haven't tried Groovy but in my opinion Ceylon strikes a nice balance between Scala and Java.
I agree that there are a lot of languages that do Groovyish things, and that does make it easier to do without Groovy, but still none of them hits that sweet spot quite the way Groovy does. Groovy is still what I'd like the next version of Java to be.
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.
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..
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).
I tried to install the Groovy plugins on a default Eclipse installation and never got the same result I got on the bloated default GGTS installation. But even with GGTS I had a mediocre experience at best. I tried the commercial version of IntelliJ two years ago and it was okay, but still lacking compared to the Java autocompletition. I'm really happy that the situation is better now.
As I use Groovy more of a host for DSLs (like Gradle or Spock), I hope tooling for this areas will improve. In my eyes, this is Groovy's sweet spot.
As I use Groovy more of a host for DSLs (like Gradle or Spock), I hope tooling for this areas will improve. In my eyes, this is Groovy's sweet spot.
Auto-completion is excellent now. I'd suggest you give it another try.
> I'd add the really bad IDE support.
I find IntelliJ support quite excellent.
I find IntelliJ support quite excellent.
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.
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.
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.
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).
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.
Interesting. Specially that you decided to make use of JSR-223.
Good luck for the business.
Good luck for the business.
Linked site over quota. Cached:
http://webcache.googleusercontent.com/search?q=cache:tVxs2fJ...
http://webcache.googleusercontent.com/search?q=cache:tVxs2fJ...
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.
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.
Kinda robs people of ad impressions though
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.
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: 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.
"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.
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.
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.
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.
Also, improvements in the Java language are eroding it's raison d'être.
Even with a big step like Java 8, Java is very very far from being comparable to more modern, expressive languages.
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.
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.
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.
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.
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.
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.
Netflix use Groovy quite a lot of.
Gradle is heaven for anyone who's ever had to work with Ant in earnest. The programming language is actually a language, not a horrifying accidentally-Turing-complete DSL!
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.
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).
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.
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.
[deleted]
"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:
and Grails over Rails:
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.