If you work on an older and large rails code base, you can easily find the programmers who came from more "formal" languages like java.
They build layers and layers of code to "isolate" rails and end up with big ball of mud. Once you do that you have to keep wrapping and adapting, and commanding, and querying and it takes a gang of more than 4 developers to maintain a feature set that could be done with 1 good rails dev.
Code is liability. Features are the asset. Well written rails has one of the best bang for the buck for lines of code per feature.
> Could you give some examples of what the use cases are where Rails makes it hard to stray from the beaten path?
Rails is amazing for greenfield projects. It will automatically do things for you which will greatly reduce the amount of boilerplate you need to write as long as you follow the framework's conventions.
However, Rails has a less than stellar reputation from those who have maintained long lived projects which use it. Rails' conventions encourage the use of fat models where business logic is implemented in the models themselves.
With the default scaffolding Rails provides, every single model and all of this business logic ends up in the project's app/models/ directory without any separation between different features. Because the default doesn't cleanly separate business logic with well defined boundaries this means that Rails apps tend to evolve in a way where everything starts to become tightly coupled with everything else. When the business requirements for the application inevitably change this tendency towards tight coupling between models makes it difficult to make major changes to existing code.
I've also seen hacky workarounds used in Rails based apps which exist to make complex business logic work (e.g., saving one model doesn't implicitly trigger hooks for business logic on other related models). These hacky workarounds usually break the conventions Rails uses and ends up requiring extra boilerplate to be added elsewhere in the application.
Some developers try to avoid this by hand rolling more architectural layers (e.g., "Java/Go/Node.js/OOP like") on top of Rails to try prevent this, to varying degrees of success. Other frameworks (e.g., Django) try to encourage developers to separate different features into distinct modules to try and prevent them from being tightly coupled with each other.
> Long-lived rails apps are a nightmare to work with, in exactly the same manner as long-lived java, python or php apps
Agreed that tech debt and bad architecture is everywhere. However, from my experience there is a difference in how much work it takes to evolve a project towards something that's less of a nightmare to work with.
