why should one count on groovy and grails rather than java

[mohd ayaz akhtar]

why should one count on groovy and grails rather than java

[Vikrant Pandit]

Groovy home page says it all http://groovy.codehaus.org/

Groovy
* is an agile and dynamic language for the Java Virtual Machine
* builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk
* makes modern programming features available to Java developers with almost-zero learning curve
* supports Domain-Specific Languages and other compact syntax so your code becomes easy to read and maintain
* makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL
* increases developer productivity by reducing scaffolding code when developing web, GUI, database or console applications
* simplifies testing by supporting unit testing and mocking out-of-the-box
* seamlessly integrates with all existing Java objects and libraries
* compiles straight to Java bytecode so you can use it anywhere you can use Java

However, Groovy will not replace Java in short/medium term. There are tons of legacy Java application and platforms where Groovy is not not present ( embedded devices).

[Vyas Sanzgiri]

Groovy/ Grails will NEVER replace Java. Heck, it was never meant to do that. It is an easier way to get simple things done.

For more complex requirements, I would turn to Java

[Gregg Bolinger]

Vyas Sanzgiri wrote:Groovy/ Grails will NEVER replace Java. Heck, it was never meant to do that. It is an easier way to get simple things done.

For more complex requirements, I would turn to Java

Vyas, this kind of statement seems to be a very common theme for you. It might be just the way that you are stating it but with how I am reading it I must say that I think you aren't entirely correct. I don't think anything knows if groovy will replace Java or not. From blogs and tweets I'd say scala is a better bet right now. Not because it is better than Groovy but because it is what has all the buzz right now.

With regards to groovy being good for simple things, and turning to java for difficult you're half right. The beauty of groovy is that is IS java. You can write pure java code in groovy scripts and it will run. You can also create classes, objects, interfaces, enums, etc in groovy and use them in your java code (so long as you compile the groovy code). The only time Java is a better alternative, IMO, is when performance is an issue. Groovy is slower than pure java, it always will be, because of all the reflection going on. But in most applications, jvm executing bytecode is not your bottle neck. And until it is, groovy is an awesome alternative to pure Java. When bytecode execution becomes your bottle neck, write that code in Java.

[Vyas Sanzgiri]

Gregg,

I see hype about Groovy and Grails all around. All speakers and consultants talking about Groovy, Scala etc. But when I ask them to name one web application out there that uses such technology to run their business they fail.

I have read numerous books about Groovy and Grails and I have tried and tested this technology. I can also proudly (or lack of it) say that we have tried (are using) such cutting edge technology to run our business. But it falls short :-)

As far as I am concerned CRUD is not everything. Ms Access does a better job at CRUD than Grails!!

Groovy on Grails is much slower than Java and also it is a memory hogger.

[Dave Klein]

Vyas Sanzgiri wrote:For more complex requirements, I would turn to Java

I would rephrase that a bit: For more complex code, I would turn to Java. That's all you'll gain for most of the project. With the exception of a few cases where byte code execution time is the bottleneck, as Gregg pointed out.

I worked on large Grails application for the State of Wisconsin that is in production now. I am currently working on another large, mission-critical Grails application for my current employer.

You can find many other examples here: http://www.grails.org/Success+Stories

I think it would be worth your while to give Groovy and Grails another look.

Dave

[Gregg Bolinger]

Vyas Sanzgiri wrote:Gregg,

I see hype about Groovy and Grails all around. All speakers and consultants talking about Groovy, Scala etc. But when I ask them to name one web application out there that uses such technology to run their business they fail.

I have read numerous books about Groovy and Grails and I have tried and tested this technology. I can also proudly (or lack of it) say that we have tried (are using) such cutting edge technology to run our business. But it falls short :-)

As far as I am concerned CRUD is not everything. Ms Access does a better job at CRUD than Grails!!

Groovy on Grails is much slower than Java and also it is a memory hogger.

You might consider writing up an article or 2 as to why Grails/Groovy fails for you. I'd be interested in reading your findings.

[Vyas Sanzgiri]

mohd ayaz akhtar, as I said and the posts prove - try it but with caution. If it suits you well and good

(I am not going to keeping replying but stick with the original thread)

[chris webster]

Vyas Sanzgiri wrote:Gregg,

I see hype about Groovy and Grails all around. All speakers and consultants talking about Groovy, Scala etc. But when I ask them to name one web application out there that uses such technology to run their business they fail.

I have read numerous books about Groovy and Grails and I have tried and tested this technology. I can also proudly (or lack of it) say that we have tried (are using) such cutting edge technology to run our business. But it falls short :-)

As far as I am concerned CRUD is not everything. Ms Access does a better job at CRUD than Grails!!

Groovy on Grails is much slower than Java and also it is a memory hogger.

Hi Vyas,

This thread also seems to be looking at the question of enterprise grails applications, and I'll include another plug for what I think is an interesting enterprise application for re-insurance risk management PillarOne which uses Grails and is being developed on an open-source basis by a group of companies including the Munich Re, one of the world's largest re-insurance companies.

It's early days for Grails, and I remember that when Java first emerged, and it took several years for the first serious Java-based enterprise web applications to appear (and several more years before these were actually usable). Although maybe that was partly because it just takes so darned long to build anything in Java! Grails, by contrast allows you to develop applications far more quickly, by building on the experience of the last 15 years of Java enterprise development as well as the use of innovative tools such as dynamic programming with Groovy. If you like spending months on every project re-inventing the wheel in Plain Old Java, great, but for most of us regular human beings, the idea of being able to take advantage of these new tools for making our jobs easier and more productive seems pretty appealing.

As for CRUD, well, if you're relying on Access for your enterprise database applications, you've got bigger problems than whether or not to use Grails!

[Peter Ledbrook]

LinkedIn also use Grails for one of their customer applications:

http://blog.linkedin.com/2008/06/11/grails-at-linkedin/

Cheers,

Peter