Totally agreed.
I guess this is just new fashion, some people keep posting "java dead" to make more hit so that they can be more populor on the cyber while they are still using Java everyday.

My old company had hired someone like Paul (someone can be google'd), they designed a PHP intranet site, claimed cheaper, and after 7 months, the guy gone with the half built website and we had to get some one to take care of the PHP shit, and the website became unmaintainable (the website was built on top of a third party web calendar, in the code, it connect DB multiple times, never close connection, always create the session, copy & paste everywhere), finally company has to hire several PHP people to maintain the web, and the website kept down every couple days, no one can tell what caused the problem.

That's my story of PHP, IMO, those script lang like PHP, Ruby, it's good only for build some small toy website.

Grails has been designed to fill in an empty spot for Java developers: productivity when building web applications.

I personally don't care how Grails scores against Ruby on Rails and certainly not in terms of popularity.

Grails has been designed to be discussed on the board level of large software development companies and I've personally witnessed this happening. Adaptation of Grails in enterprise settings is starting slowly and will take in 2007.

As I'm sure you understand by now we don't care about Ruby on Rails. Grails is aiming at a different kind of animal.

The trouble with Groovy is not that its non-buzzworld compliancy any more (it was when all things j-spelled where buzz). The problem of Groovy is the same as the one that stalled Jython and which will plague JRuby. The problem of all those j-spelled interpreter is ... Java.

Applications of a bytecode interpreter implemented in C (like Perl, Python, PHP, Seamonkey's JavaScript or ... Ruby) will allways be significantly faster to run and leaner on memory than the equivalent implemented in Java.

Don't take me wrong: I'm a professional Java developer and now that Sun's JVM is GPLed I expect the language to improve a lot more and a lot faster that it did for the last ten years (I mean, why has sprintf string format function been included in 1.5 when it's been available everywhere else for decades ... if not for Sun's "Not Invented Here" complex).

However, to improve something you first need to identify its shortcoming and evaluate wether they can be fixed or not.

Kind regards,

ps: regarding your views on CPython, consider that this VM has been successfully applied by leaders such as Google and Youtube to glue together high-performance web applications, which is something Groovy is not even close to achieve ;-)

Please explain your statement "Sun effectively "endorsed" Ruby over Groovy". Have I missed something. I know Sun hired the two JRuby guys to work full time on it. That is certainly an endorsement of JRuby. Groovy has it's on JCR which is also an endorsement.

Ruby is now the current "big thing". The problem with current "big things" is they are very vulnerable to "the next big thing".

I'm a Java developer working in a large organization with a HUGH existing code base. My company is not going to switch to Ruby anytime soon. The great thing about Groovy is I can use it NOW at work to do all kinds of things to make me more productive in the Java environment. This is mostly throw away code so I don't have to fight the "let's switch to Groovy" battle with the rest of the organization. JRuby could step in and fill this space but I don't think it's there yet. Right now it just doesn't work as well with Java as Groovy does.

Most Ruby zealots I know seen to believe that Ruby is the long awaited silver bullet that will quadruple productivity and that Java must die. To succeed they must win the "let's switch to Ruby" battles in the corporate world. In my 20 year career, I've seen many great languages(Pascal, Smalltalk, Lisp, etc) loss the battle. I would love to see Ruby or Groovy kill Java. For now, I'm happy to be writing my production code in Java and my mocks in Groovy.

You are correct that Groovy is aimed at Java programmers. Last time I looked, Java programmers are a major force in software development. With the investment companies have made in the JVM based technologies, that's probably not going to change significantly anytime soon. And why are companies and the open source community that have used CRuby / RoR and found it doesn't scale well are looking at JRuby? What?! JRuby faster than Ruby?! How can that be?! Scale a RoR app using a WebSphere cluster - oh, the horror!

Let me think....how many developers have I met over the last 20 years that have written something with wxWidgets...umm...none. Ok. I'll stop using Groovy. And while I'm at it, it sounds like I should really dump my Java skills altogether and start looking at Python and wxWidgets jobs. Thanks for the insight.

Look, if you love C and hate the JVM, Groovy or any other JVM technology probably isn't of interest you. If you have lots of experience with Java and need to interact with a JVM, Groovy is pretty attractive.

Luarant - Groovy is performant (and readable) enough for important financial applications at companies around the world. Peruse the Groovy/Grails user lists and you'll see, as Steven indicated, Groovy and Grails is being taken very seriously.

I've used JRuby now, and expect to use Groovy in the future. Both are great languages , and both will have their place. For Groovy to step out of Ruby's shadow, it's going to have be more than just a copy of Ruby on Rails (e.g. Grails).

This 'more' could be the fact that Groovy's language syntax is a lot closer to Java. Ruby is hardly difficult to learn, but for Java programmers, Groovy is easier still.

Applications of a bytecode interpreter implemented in C (like Perl, Python, PHP, Seamonkey's JavaScript or ... Ruby) will allways be significantly faster to run and leaner on memory than the equivalent implemented in Java.
Java... a bytecode interpreter written in C. :D The big thing with a lot of these efforts isn't to implement an interpreter in Java, but to get dynamic languages compiled to JVM bytecode. Either way, though, nobody pushes Ruby on the "performance" tip, even in the C version.

Please explain your statement "Sun effectively "endorsed" Ruby over Groovy". Have I missed something. I know Sun hired the two JRuby guys to work full time on it. That is certainly an endorsement of JRuby. Groovy has it's on JCR which is also an endorsement.

Ruby is now the current "big thing". The problem with current "big things" is they are very vulnerable to "the next big thing".

Having a JSR doesn't represent endorsement from Sun. Indeed, I would say the whole OSGi vs JSR-277 thing would demonstrate that point clearly. At the same time, seeing Charles working on the JRuby runtime and Tor working on Ruby support in NB (and doing big work) while Groovy simply *is* the more mature system, is disheartening to the Groovy users. I don't have a "horse in the race," but I understand their feeling.

Ruby is now the current "big thing". The problem with current "big things" is they are very vulnerable to "the next big thing".

I'm a Java developer working in a large organization with a HUGH existing code base. My company is not going to switch to Ruby anytime soon.

It is hard for me not to see the comparisons between that statement and the statements re: C++ vs Java in the 90s.

You are correct that Groovy is aimed at Java programmers. Last time I looked, Java programmers are a major force in software development. With the investment companies have made in the JVM based technologies, that's probably not going to change significantly anytime soon. And why are companies and the open source community that have used CRuby / RoR and found it doesn't scale well are looking at JRuby? What?! JRuby faster than Ruby?! How can that be?! Scale a RoR app using a WebSphere cluster - oh, the horror!

I agree with you 100%, but I think you jump the shark right at the beginning. This isn't even about the enterprise space and what people are using now. The focus on Ruby -- as well as the GPL for the JDK, getting Glassfish in the Linux distros -- is all about pulling users from LAMP and to a lesser extent, .NET. That is really my point. Groovy is great. We use it regularly (in limited scopes) at the office and are generally happy with it, but I can certainly understand why Groovy isn't featured prominently on Sun's medium term plans.

I endorse this view. Sun has done a mistake by not patronizing groovy. Groovy is relevant to any java shop right now. Grails is a solution that can match RoR with tried and tested frameworks in java. JRuby may be great, but only when it is out.

> Java... a bytecode interpreter written in C. :D

But not *for* C.

Tcl, Perl, Python, PHP and Ruby "glue" C libraries and system API into applications, making the most of native, plateform specific bindings.

Java on the contrary was intentionnaly designed as a "world apart" where everything - including sprintf - was to be reinvented ... in Java. The end result is that MySQL JDBC drivers are up to ten times slower than PHP's equivalent.

Java *has* a problem of performance *by design*.

Denying it won't solve it.

> The big thing with a lot of these efforts isn't to implement an interpreter in Java, but to get dynamic languages compiled to JVM bytecode.

What's the difference?

The bytecode compiled is still Java: made for a VM that trade a lot of space to reach C++ speed ... and which was designed and implemented for static types.

All bytecodes are not made equal.

That's why Jython rewritten for Microsoft's CRL as IronPython runs Python's benchmark suite four to five times faster.

Kind regards,

Applications of a bytecode interpreter implemented in C (like Perl, Python, PHP, Seamonkey's JavaScript or ... Ruby) will allways be significantly faster to run and leaner on memory than the equivalent implemented in Java.

- bla, bla, yeah and if you write everything in assembly it will be even faster (this argument is old, boring and irrelevant). If performance is a problem in your application and you can't solve it then you've choosen the wrong technology. I have been developing in Java for 8 years and never encountered an unsolvable performance issue. So why is it a problem for Java exactly ?

I heard some good things about Groovy so I decided to check it out. I did some reading one night. The next day I told eclipse to go get the Groovy plugin. I pick a simple out a simple Java class from the thousands in our code base at work and rewrote it in Groovy. I ran my java junit test and they passed. The debugger stops in the Groovy code or the Java code. MAN IS THAT COOL.

Let me summarize. Reading about it one night. Coding in a large enterprise java environment the next day. Try that with Ruby or JRuby.

I agree with Paul Lee. I have also been programming for 20 years and I have seen things come and go. I have a similar problem. We have a huge C++ code base. So when moving to C# and .Net we want to leverage as much of code as possible. But most importantly we want to leverage the skill and experience of all my existing developers. This applies to the Java space also. It is easier to undertake incremental "next big things" than radical "next big things".

Ahh well.. call me crazy but I honestly fail to see a future for Ruby. I have to admit, I've also been caught by the hype, even made a "nice" rails based website.

Ohh yes, it works.. But that whole ruby thing is such a mess, I honestly have not a clue what features the next release of rails (or ruby) will support and (more importantly) ditch, what plugins (dare i say libraries) will cease to work / be unmaintained etc. No, i'd rather be non-agile but be sure may code will also be usable in the future.

As long as Groovy stays closely tied to java (and, of course, it will as that is its design) I'm pretty sure the huge codebase available to Groovy will make sure that Grails has a longer, perhaps less popular, lifespan than the beast called Ruby on Rails. And Ruby will die with Rails.

It's nice to see the increased awareness of scripting languages, but it will need so time to separate the wheat from the chaff.

The powers-that-be have been pragmatically, but bitterly, awaiting a killer ruby app for the last seven years. Everyone has the right to sell more books and services. Training, speaking and coding services.

What's the story with Ruby and unicode again?

If Grails is successful at replicating Rails, while it'll take some time, it will give Rails a run for its money. A lot of the people switching to Rails are Java folks who make that huge leap because of the productivity benefit. As a Java developer, who also ran a technology department in a financial company all based in Java, I really like the idea of Grails. My main gripe about Ruby/Rails was the idea of dumping huge piles of quality code for marginal productivity increases (yeah, debatable, I know). Even if my productivity went up, there's a ton of existing code that you're throwing away. We never would've considered Rails for the financial department. However, if Grails had been around and stable at that time, not only would we have considered it. We would've put it into some of our internal apps on a trial basis. There are many, many, many shops out there just like my old one.

Groovy/Grails on the JVM is too slow? Sorry, I remember people saying that about Ruby. The response was that you would make it up in productivity. You buy bigger servers for speed. Much, cheaper. Old myths die hard. Swing is slow. Java isn't. Is the same code in Ruby faster than Groovy? Probably. Much faster? Probably not. Where do you spend most of your time? In the database, business layer, etc. You generally spend a fraction of the time in the render phase. This argument seems defensive to me. The whole point of Ruby/Rails is that productivity trumps other considerations. A well tuned servlet is going to destroy a Rails app, but that's not the point. Rails is better because you produce more quicker. I agree with that logic. Now somebody is applying that to the Java realm.

Rails is cooler now, and I've never written a line of Groovy, but just hearing about the concept gets me excited. I bet there are many Java people who feel like the leap to Ruby/Rails is too big. There is no leap to Groovy/Grails. That's a very compelling argument. Cool turns to lukewarm very, very fast if you don't have something unique behind it.

My $.02

Given time Grails will beat the pants off of RoR. You have all the productivity plus all the Java stuff. I don't even worry about JRuby because like JPython it will end up always catching up to its "C" cousin.

Grails has all the bindings available for java. This includes GTK, WxWidget, as well as OpenGL, SDL, directx, etc etc.

Groovy can deal CGI without problems:
http://sourceforge.net/mailarchive/message.php?msg_id=38049797

I agree with Paul Lee's (and others) comments. I like Groovy because it was built from scratch to play great with Java. I can use it now in unit testing (one of its original use cases, and a potential killer app for it IMHO). It is a nonsense to even consider fighting battles with Java, or Ruby - why bother? It is a great tool in our toolbox, use it appropriately. I'm using it for unit testing, I'm using it for scripting within products. It will not replace Java, neither will Ruby. The fundamental advantage of Java over Groovy and Ruby is that it is statically typed, which - amongst other things - enables (note my use of the word "enables") good tooling. While Ruby is hot right now, I think Groovy is in a different league, its going to be a slow burner, but in the end may burn more brightly and for much longer.

What does Ruby have that Groovy does not? I predominantly Java guy who has also worked on a RoR app, so I have some basis to look at both. My answer: Not sure, but I would say that Ruby can be more expressive, and more productive in the right hands.

On the other hand, I know what Java has: A bazillion running, big E Enterprise applications and kagillions of trained developers. Groovy, and Grails, gives the Java world fairly seamless add-on to achieve Ruby-like goals.

So while I think that Ruby will continue to stake out more ground for non-Enterprise apps, and as a pure scripting tool, it does not have advantages sufficient to kick Groovy out of Java's house.

I think there are several misunderstandings here about Groovy. Groovy does not aim to kill Java. Groovy wants to help Java programmers to be more productive. And it gives Ruby people a home who don't like the lack of integration from JRuby. But especially Groovy doesn't try to replace PHP. Groovy is not a language designed for usage in web servers, it is a general language as Java or Ruby are.

It is sad that Ruby is only so well known because of RoR. If something happens to RoR then Ruby might die with it. And because of this we don't say Grails is Groovy. Grails uses a huge amount of libraries well known to the Java community, like Spring and Hibernate for example. You can even use Java to do the stuff you want in Grails. Groovy is an important part of Grails, but it is not the only way to do something there.

But because many things can be expressed much shorter and because it is so easy to switch to Groovy there is no real harm in making a class in Groovy.

And using Groovy doesn't mean you are loosing code completion in your Java classes. You can use every Groovy class as if it where a Java class when it comes to code completion.

As a Java developer, I think jumping ship from Java to Ruby purely because of the buzz is really stupid. I think it is a costly move and seems more like a cop out (as least form what I have been hearing). I've also worked in both groovy/grails and some ruby/rails. I still like Java because you can practically build anything with it, and it has proven itself in industry as the language to go with when it comes to performance and scalability in the enterprise environment. I like the support base and that is one thing that will not yank me away.

I also work with developers who have jumped ship (possibly because they are not comfortable with Java), and I hear frustrations everyday about their stuff with R/R. One major advantage that I like with G/G is that I am still able to work in an environment where I can leverage or move between both static and dynamic environments. I think Graeme Rocher and his team really thought through a lot of things before putting this framework together.

Grails is not Rails ... it differs significantly at the lower layers and focuses on leveraging proven technologies and frameworks as part of its arsenal ... such as Spring, Hibernate, SiteMap ... etc. These are technologies that I know work and are more robust. I am seeing for e.g, the inadequacies of Active Record as compared to Hibernate with regards to our R/R projects.

One of the major consideration in creating Grails is the investment companies already had with their enterprise application. That in itself speaks a lot for companies considering the move. So what if Sun doesn't support the G/G movement, others are (e.g. Oracle). Further more ... I am impressed with the aggressive improvements taken towards G/G. There are many advantages for the Java folks to go with G/G ... all they have to do is check it out and quit relying on buzz words. I know that many Java shops now use Groovy in one way or another to help accommodate their application and development environments (especially in the testing area). There are essentially at least six other competitors in this area besides G/G, such as Trails, AppFuse, Adobe Flex ... etc. Let the battle rage ... I am already liking whats happening in the Grails arena.

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9053725&source=rss_topic63
IntelliJ now have both with clear (for me) advantage for Groovy. SUN can now only tag behind as eclipse has one too already. I wouldnt be surprised to see a netbeans plugin for Groovy very soon. And I cant blame SUN for being consistent in missing out the right Java technology orientation and vision.