What does it mean for a programming language to be "on rails"?

To address your confusion with the metaphor (though it has been answered in other words under your question):

Groovy is to Grails as Ruby is to Ruby on Rails, but what does that mean?

Grails was a web framework built on/with the Groovy programming language to do the same thing for Groovy that Rails (a web framework for Ruby) does for Ruby.

What does it mean to be "on rails"?

The answer to this comes down to the essence of these web frameworks.

These web frameworks (Grails & Rails) are built on the premise of "convention over configuration", which means that using common conventions to develop web applications can lead to higher productivity and more maintainable applications (this is a gross generalization). And by defining a convention and sticking to that you will find that your applications are easy to generate and quick to get up and running.

This is what it means to me to be "on rails", just like a train. When a new train route is developed there is no worry about reinventing the way the train will get from one place to another, it's been solved by a single convention for decades: rails. Just as the tracks on a train route constrain its path from two locations, convention-based web frameworks use conventions to the flexibility of application developers so that they can concentrate on what the essential business problem of their application.

One key benefit of a convention for a web framework is that the web framework can now make assumptions on how certain layers of the application hook together. In Rails, one can usually assume that if one's database table has a plural name, the ActiveRecord class mapped to that table will have the corresponding singular name. Consequently, Rails code generators can consume the data-mapping information to generate data access code such as dynamic finders, migrations, lazy-loaded association traversals, etc. This data access code in a configuration-based framework is laborious to code by hand.

Several people have mentioned the technicalities of what makes Rails/Grails what they are. Several people have also mentioned "convention over configuration" as being the "rails" in Rails/Grails. This is getting closer to the truth. But this is just one characteristic of the broader philisophy of Rails, which is the concept of opinionated software.

Opinionated software can't be described in only technical terms; it's a philosophy; an ethos; an attitude. Like it or hate it, that is what's at the heart of Rails.

Here's an exceprt from a 2005 interview with David Heinemeier Hansson, creator of Rails:

Rails is opinionated software. It eschews placing the old ideals of software in a primary position. One of those ideals is flexibility—the notion that we should try to accommodate as many approaches as possible, that we shouldn't pass judgement on one form of development over another. Well, Rails does, and I believe that's why it works.

With Rails, you trade flexibility at the infrastructure level to gain flexibility at the application level. If you are happy to work along the golden path that I've embedded in Rails, you gain an immense reward in terms of productivity that allows you to do more, sooner, and better at the application level.

There is also a later interview that further explores the subject.

So being 'on rails' is a metaphor for being 'opinionated', which is why it is named as it is. That and the fact that "Ruby on Rails" is alliteratve, which any journalist or writer will tell you, is a sure-fire way of hooking people's attention.

I think a framework that strives to be "rails-like" refers to several things:

• model-level: an AR-patterned ORM (rather than datamapper), migrations or some automated schema and model-layer management, handling foreign keys in the application (not in database schema, and also not using stored procedures or pure DBMS logic)

• TDD encouraged: automatically generated skeletons for unit-tests,

• naming conventions connecting database table names and model names, controller and view actions and HTML templates

• streamlined route recognition and route generation scheme

• emphasis on REST architecture

• integration with ajax libs: RJS, prototype and scriptaculous