yeah, I think he's just maturing as a developer and rails was his first love. Just about everything he mentioned aren't particular to rails, it's just a natura

yeah, I think he's just maturing as a developer and rails was his first love. Just about everything he mentioned aren't particular to rails, it's just a natural consequence of decisions being made. For example, he complains about the coupling between active record and the rest of the system. And he's not wrong, but the thing is, this happens with every ORM in existence, including data mapper style libraries. The reason for this is easy to understand, people sprinkle ORM code throughout their codebase instead of having a proper DAL (they treat the ORM as the DAL rather than a mechanism for fetching data). Any ORM that you use where you sprinkle it directly through your entire codebase is going to experience tight coupling. And you can see it in a lot of ORM designs where the ORM itself will create mechanisms for "query re-use" and most of them are actively damaging to code maintenance. I remember the first time I read the treatise on "Object-Relational Mapping is the Vietnam of Computer Science" and being surprised that people actually used ORM's that way. I guess my point is that every decision made causes problems, sometimes those problems are obvious in the short term and sometimes they're not and they take longer to become obvious. This author sounds as if they fell in love with Ruby and have now worked with it long enough to start seeing the problems but they're blaming Rails when a lot of the issues are deeper than that. Rails may exacerbate it, but these problems are not unique to Rails. And if I may, part of the churn we see in tech is due to people constantly looking for the perfect solution (non-problematic in any way). That's not engineering, any jackass can point out problems (theoretical or otherwise). What I'm saying here is I think the author is maturing but they need to consider that maybe Rails shouldn't be the only tool in their toolbox.