I think Rails is good for a consultant who wants to pump out a lot of relatively generic apps. You pay a constant upfront cost to learn the Rails magic and the conventions, and once you know that stuff, it makes greenfield development faster.

If you're doing a single big project, Rails is less attractive. The upfront cost is amortized over just one project, and the magic makes it a bit harder to stray from the beaten path when you need that.

Could you give some examples of what the use cases are where Rails makes it hard to stray from the beaten path?

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

> 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.

My experience has been different. Rails is good for everything from small internal projects to larger, enterprise level projects. Like all languages and frameworks, it requires discipline and good practices for the code to remain robust and maintainable, but functionally I’m not aware of anything that fits what you describe in your second paragraph.