Reading the Ruby Source to Understand Rails Idiosyncrasies

I can't agree with this at all.

Rails has default and reasonably sensible idioms for expressing common concepts. They work in most cases, but there are of course situations where you want to implement something in a way that results in an impedance mismatch with the framework.

In these cases, it's embarrassingly easy to compose different behaviours, or indeed to write entirely custom ones, in order to achieve the functionality you require. At the end of the day, it's Ruby with some helper libraries, and developers are free to use as much or as little of these as is required.

If there's a problem in this vein with Rails, it's that the magic makes it almost too tempting to twist apps into the "Rails way", even when it's not appropriate. Good developers will be aware of this, and use the correct approach.

People forget that "Rails 3" was actually Rails merging with Merb. A lot of hard-coded inflexibility of Rails 2 had to be extracted out, and the framework became much more malleable as a result.

When I hear people talk about being stuck to a certain path with Rails, I wonder what they are talking about. Then I think back to Rails 2 and think, "oh, right....".

Rails still encourages a certain path by convention, but it is much easier to deconstruct than before.

It's interesting because I've had exactly the opposite experience with Rails in production environments. I prefer to prototype with something simpler, but have found Rails pretty solid for delivering full websites with a complex back-end and tens of thousands of daily users (hardly web-scale, but not insignificant either - probably most sites fall in this bracket). Not that it's the only solution in that space, there are lots of other suitable frameworks, but I'd say it's not bad. It will use more resources than some other solutions, so it's definitely not the most efficient in machine time, but it makes up for that IMHO in being efficient to work with.

We're running some relatively busy sites with Rails and have seen no issues with maintenance or performance (due to caching), and I don't foresee any problems simply because for most web applications you can get acceptable performance up to very high scale by caching selectively. The support for russian-doll style caching and automatic expiration on db changes is pretty good, they're not bad about getting rid of cruft, and over several years I haven't run into any significant maintenance issues. My biggest worry with Rails is security, but that has improved, and is probably better than roll-your-own frameworks anyway.

Having come from Rails 1 and quite a few other web frameworks/CMS solutions, I don't really see Rails as having a lot of magic nowadays, though it does have lots of little shortcuts like scopes, and lots of helpers for everyday tasks like mailing, querying, dates, rendering templates etc. So I've found it a help rather than a hindrance and one of the few frameworks which stays out of your way enough to be worth the trade-off. In particular I like that the conventions mean that when you come back to a project after a few months the decisions on naming and placing functionality will all make sense, if you've followed those conventions.

It would be interesting to know which specific areas you've seen problems on, if only as a warning for others using Rails. I can imagine for example if you didn't want to accept the database naming conventions, or the file naming conventions it'd be a pain to work with and constantly tripping you up.