While I agree that ActiveRecord is really good in a lot of ways, the entire ecosystem around it is a giant clusterf* waiting to happen, and it always does. Fat

While I agree that ActiveRecord is really good in a lot of ways, the entire ecosystem around it is a giant clusterf* waiting to happen, and it always does. Fat models, callbacks, concerns, scopes... changing a model reliably without 100% test coverage is damn near impossible for any relatively complex application and knowing what your model is going to do on any given call is a nightmare when you have a dozen+ callbacks/concerns/scopes/whatever. That 'oh crap I need to deploy a big change, is it going to work right?' feeling never, ever goes away. I've used both ActiveRecord and Entity Framework extensively. And while Entity Framework definitely has it's drawbacks, it doesn't get any better than Linq in combination with static compilation for a large and complex code base with a lot of moving parts. And yes, "don't do that" is all well and good when it comes to the 'right' way to do things in Rails/ActiveRecord, but when DHH himself is driving the callback train at full speed and you take a project over from someone who jumped on the bandwagon and didn't actually know how to properly apply these tools to the code, it's going to be a pretty nasty wreck. You can be damn sure I'd rather take over and refactor a large, messy C#/Linq/Entity Framework project than a large, messy Rails/ActiveRecord project. Also I could never get over the fact that Rails developers for some reason treat foreign keys like it's ebola. "It's just not the Rails way" is not a good answer for not using foreign keys.