With each new version of RoR gems just stop being compatible without replacement, and its a fairly significant effort to migrate everything to the new shiny being introduced. In fairly stable projects where there isn't much feature churn/replacement, you pretty much have entire sections of the codebase that never move past the version they were originally written in. You're constantly maintaining controllers/models written in RoR 3.2/4/4.2/5/5.1 styles since its incredibly difficult finding which features were used, but they still kinda sorta mostly work, until they silently don't.
The difference compared to other frameworks/languages is that Rails is very heavily powered by "magic". Every other tech explicitly configures and calls features being used, but Rails is mostly held together by "convention", but convention evolves. How do you search for things like "the filename of this must match the class name of this" or "the method name must match this database feature". Nevermind the metaprogrammed methods that aren't documented anywhere. The convention evolving as developer preferences changes is generally a good thing and keeps RoR from becoming too dated but it is an expensive maintenance burden.
I quite like Rails and it's still my first choice for personal projects/prototypes. But I'm definitely souring to it for long running professional work.
Furthermore, as the project grows, you need to introduce something more/bigger than MVC and people put these files everywhere. Sure it's a management problem but it doesn't help that people don't do the right thing by default.
In general, there's a breaking poing that you will very soon hit when you try to just pile things on top.
It's mostly the "magical" parts like before/after hooks.
I guess when you get into inheritance perhaps. When you have an inheritance chain, which hooks are firing and in which order? That gets confusing fast. But, that also doesn't feel Rails-specific at all to me.
Rails gives you some ways to shoot yourself in the foot, but what language/framework doesn't?
When you are tracing a bug and are trying to do step-by
-step debugging, it has been hell.
I have an expansion set up in my text editor that spits out `Rails.logger.debug("[jbootz] ")` and then I just do `tail -f log/development.log | grep jbootz`. I also have iTerm set up to highlight any lines containing "jbootz", so it stands out when it's mingled in with other output. (I just picked "jbootz" as it's a unique string)
In general that's the strategy for Rails debugging or really any dynamic language where the editor/IDE can't reason about the code like it can with a static language.... lots of debug output and then get a little creative with how you filter it in your terminal.
Helps to use an terminal app like iTerm that lets you use split panes so you can look at multiple filtered views of your log output at once if you like.
Quickly jumping to definitions? Even RubyMine can't do it.
Still, as far as definitions go? I don't know. I just grep for "def foo" (if I don't know what file it's in) or use my editor to jump right to the file where it exists (if I know where it is, which is usually the case)
Not as slick as the editor/IDE actually being smart, but I don't really find it to be a friction point.
... that seems unnecessarily complicated compared to using byebug, or hell, the RubyMine debugger.
But any large enough project needs rules for placing files/classes
I don't see how Rails failed in that way
I do agree there are some "magical" stuff like hooks that can be easily abused and introduce bad coding habits/patterns
Wish I can turn them off per class (not for the whole app since they are still sometimes useful)
I don't see how that's a Rails-specific problem.
Before Rails, working in the wild and wooly world of Microsoft web dev (with occasional PHP thrown in) I saw some real horrorshow web apps. People hacking together their own confusing and misthought architectures. And those horrorshows were rule and not the exception.
The standardized structure of Rails apps is such a breath of fresh air. It's so nice to step into a Rails codebase and basically know where most things are most of the time.
Admittedly it's also nice to step away from Rails for smaller, simpler apps.