Groovy doesn't have any sort of ORM framework itself, though it does have a slick-seeming SQL interface. I haven't actually used it, so I can't say for sure though.

Grails uses Hibernate under the hood, so you have access to the full Hibernate stack, including HQL. I suppose picking up the dialect is a bit of work, but it's never been an issue for me, even when starting. More troubling is thinking in terms of querying objects, rather than tables. That's a conceptual hurdle that took me a while to get my head around (and I still sometimes butt up against). However it does allow a far more business-model-centric way of querying which is quite nice, as well as providing an abstraction layer that allows you to extend the query language in an application-specific (and DB neutral) way.

When I said ActiveRecord didn't have a query language, I was referring specifically to querying the conceptual object store to select instances. find_by_sql doesn't even come close to that: it's nothing more than a way to do raw SQL queries against the DB connection configured for ActiveRecord. It's really more analogous to getting a Connection object from Hibernate and doing SQL against it (using Groovy's SQL stuff, or plain JDBC).

Anyway, you said that ActiveRecord doesn't have a query language. If I understand correctly what you're getting at, that's not quite true, at least in the sense that you can pass native SQL code to ActiveRecord.find_by_sql . There's certainly nothing in Rails like EJBQL, but to my mind that's OK — who needs to learn yet another dialect of SQL?

How does Groovy deal with this? I've never worked with it, although my last job was with a company that created what as far as they knew was the largest Groovy project to date. But I wasn't working on that project.

Eight years ago, CF was awesome. It blew the pants off other languages available for developing web apps quickly and easily. These days, it's a far less compelling choice. I doubt it's market share has diminished, but I feel that it's relevance has.

I wasn't referring specifically to Grails as the reason for it; I've had that opinion for quite a while. There are a whole pile of web toolkits out there now, and they're breaking some cool new ground. I wouldn't care to use a number of them, but I do appreciate what they're doing. CF, on the other hand, has done little. CFC's were a step in the right direction, but the implementation is poor in many ways. Other than that, almost all improvements have just been reinventing the wheel with CFML syntax, and often in a very limited way (consider the mess that is CFTHREAD, or the breaking of CFMAIL when CFMAILPARAM was added).

I have no doubt that Groovy and/on Grails is an exciting track to go down but I am not sure that relates to CF being less relevant; just my opinion from indicators that I see. Thanks again.

I'm not going to call it either way, but Grails definitely provides a lot of stuff that a certain set of CF developers have been crying out for, and does it without requiring as large a shift as other alternatives. I haven't done it, but I see no reason that you couldn't easily build a hybrid CF/Groovy/Grails app, and with enormously less pain than CF/Java hybrids.

I know I'm going to be doing CF for a good while since Mentor's heavily entrenched. CF's relevance is definitely waning (regardless of Adobe's sales figures). Perhaps an influx of good ideas could buoy it.

This is just what the doctor ordered. I had a similar experience with rails and python. Java is great but it has a huge learning curve and I am still very much a beginner. But I was able to dig right in with Grails and felt comfortable right off the bat.

Having support for Eclipse and Netbeans is huge.

Since Grails is all Java-backed, you can use all your standard Java tools (e.g. Eclipse debugger) to debug your apps. The runtime error template is part of your project (generated for you, of course), so you can customize to your heart's content which is handy as well.

More important, I think, is that you get far better tool support with Groovy/Grails. That lets you catch a lot of potential errors in the IDE rather than at runtime, especially if you leverage static typing where appropriate. Regardless of how good the debugging tools are, not having to do it at all is always better.

I'll be digging deeper into it at some point.