[MrDarcy]

First, props for your candor. It’s refreshing.

I do wonder if Rails is so bad compared to other frameworks that it deserves such a distinct treatment.

Over the decades I’ve worked with at least half a dozen popular frameworks that fit this description, is the same for you or is Rails truly unique in this regard?

[throwanem]

Rails is uniquely compromised by its history and by its language of implementation. Ruby is good for many things. Writing maintainable software in the absence of conventions enforced by shotgun is none of them. And Ruby's American fanbase gets off way too much on holding the shotgun.

[BobbyTables2]

Worse than Python (without Typing)?

[brian-armstrong]

100% yes. Python mostly encourages simple, stupid code. Code that you can still read while 2 beers in. Rails, on the other hand, encourages being as clever as possible at all times. Forget about local side effects when any part of the codebase can just reach in and patch another part of the codebase.

[whstl]

That's also my perspective.

Debugging can be extremely hard when there are multiple complex frameworks/libraries doing magic stuff, plus extensions by the current team.

In practice this is all very convenient when you're writing the code, but not so much when you have a production issue.

[throwanem]

Exactly so.

I'm not actually averse to a programming environment where the only ground truth is the running image. I love that kind of environment! In my editor, where worst case I dump some state when I restart, and I can just not play such dangerous games when on call or there otherwise exists a risk of winning such stupid prizes. Production has rules. Or it had better.

That said, if you want me to go back to dynamic typing, there's a fee. The grass really is a lot greener over here.

[9rx]

The thing about Rails is that it does one thing really well and beyond that you are completely on your own. Without incredible discipline, this becomes a problem because people tend to fall in love with how well it does that one thing and start dreaming up how their other problems that inevitably show up in a project of any meaningful complexity can be solved with the same kind of 'magic'. But they don't have the multiple decades of refinement and literal thousands of developers supporting their solution to give it the same polish that the Rails core has. Which means that, with almost certainty, what they come up with is going to be a nightmare.

The best of the best developers may have the resolve necessary to ignore their emotions and stick to writing 'magic-less' code when they move past the one thing Rails does well, but most projects are going to land in the laps of most developers who aren't that. I am sure we can find counterexamples of where exceptionally skilled teams have been able to wrangle Rails, but the exceptions do not make the rule.

On the other hand, when beginning in a place where writing ugly, boring, but at the same time usable code is the norm, even the average developer tends to stick with it when they need to do things that are "off the Rails". They don't have the original enamourment to get caught up in. There are plenty of developers who can still manage to screw this up too, but, again, exceptions do not make the rule.

Rails is just a tool, of course. The outcome ultimately is down to the operator. But there is a certain psychology at play that introduces difficulty. It is kind of like giving the average daily commuter, who is a perfectly fine driver under normal circumstances, a supercar with features they can fall in love with. In theory it's just a car to drive as they normally do, but they're bound to do something stupid with it when the emotions take over.

[jfinnery]

After a lot of consideration of this question (I have also all-but written off Rails work, after doing a lot of it) I think it's a combination of two things, one technical, one business-social:

1) Rails and Ruby will gladly let you make an absolute garbage fire out of your codebase, while it still technically works, and discovering how exactly the garbage fire is structured so you can start trying to put it out is unusually difficult in Rails. You don't have to make it a garbage fire, but they won't do a single thing to discourage it, and once it's bad, it's hard for an outsider to show up and figure out how to fix it, because of how the framework and language are designed.

2) Rails is often chosen by very price-sensitive companies trying to move fast, as cheaply as possible. This means high turnover, lots of enthusiastic juniors, outsourcing (often passing through multiple outsourced teams...) and often mediocre or poor management oversight.

The result is that a high proportion of Rails codebases in the wild are both remarkably terrible and impractically difficult to restore to some non-terrible state (i.e. they're the kind of cases where the right call really is to just start over—one of the things that makes them hard to work with is that a bad rails codebase is especially hard to rewrite-in-place, it's just a ground-up replacement job usually, but you won't actually be allowed to do that because see again: price sensitive, so you'll just live with an awful pace of development and poor application performance while management gets increasingly frustrated by the outcomes of their own choices)