For most parts of Rails, I agree. There is one very important one where I don't: ActiveRecord's internal behaviors are opaque enough at most levels where you care about your database to be fairly called "magic". Having to reverse-engineer ActiveRecord to make my database stop puking and to generate a make developers who know Rails but not databases not get upset that now the solution is insufficiently "Rails-y" (whether or not it is correct and whether or not it is faster than the "Rails-y" method that's causing them problems) is not great.
Fair enough, I would say that the internals of ActiveRecord/Arel/etc can be complicated but also do a lot of work. I watched a number of presentations by tenderlove and had a bit of background/interest in that area to start with. "Go watch this guy's videos about relational algebra and SQL generation" is probably not what you want to hear when there's a bug though.
By the time you've gotten there though you've certainly more than figured out how method_missing and different filename based conventions work though, you've seen what Rails is and I'd be curious to find out what you like better!
Honestly, these days? Writing my own SQL and using languages with static typing. I'll take a little longer to write code to make thinking about it easier.
I still use Ruby nontrivially for stuff like command line tools, though.
For most parts of Rails, I agree. There is one very important one where I don't: ActiveRecord's internal behaviors are opaque enough at most levels where you care about your database to be fairly called "magic". Having to reverse-engineer ActiveRecord to make my database stop puking and to generate a make developers who know Rails but not databases not get upset that now the solution is insufficiently "Rails-y" (whether or not it is correct and whether or not it is faster than the "Rails-y" method that's causing them problems) is not great.