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