Ruby on Rails

Optimizing for DRY (Don't Repeat Yourself) principles above all else in Rails creates messy, over-engineered code that becomes difficult to maintain. This pattern is particularly problematic when legacy data models no longer fit customer demands.

Rails callbacks (particularly after_save and after_commit) are prone to creating hard-to-diagnose bugs in large applications, especially those with technical debt. Developers must actively avoid these patterns or extract business logic into pure Ruby classes.

Ruby's ecosystem is tightly tied to Rails and web development, limiting its applicability. Unlike Python (AI/ML/data science) or JavaScript (browser/serverless), Ruby has not made significant inroads outside web development.

Rails has limited native support for building rich, JavaScript-heavy frontends. Projects requiring React or Vue integration add complexity and negate some of Rails' development speed advantages.

Rails lacks Language Server Protocol (LSP) support, preventing modern IDE features like 'go to definition' for function calls. This is considered a critical gap for any modern development framework.

Developers need to address resource consumption and optimization concerns in the first week of development, which diverts attention from building business value. This is a design flaw that forces developers to tackle non-core concerns prematurely.

While Rails' opinionated structure helps new developers, it can feel restrictive and create friction for those with different preferences or requirements. The tradeoff between enforced structure and flexibility remains unresolved.