[trebbble]

I've been in the guts of about five Rails codebases that were already in production, and they've all been very bad, and the badness difficult to overcome in part because of Rails and/or Ruby (which is why I hang some of the blame on Rails itself).

IME Rails codebases are a few months with a mediocre team or a few bad choices away from becoming an absolute garbage fire, and all the magic in Rails is part of why even a little of that sort of activity does so much damage.

Amazing for starting from scratch solo or with a very small team. Dangerous (mind: not necessarily bad, just dangerous) under basically all other scenarios, including ones that that sort of ideal situation might develop into. In particular, a great deal of discipline and excellent taste is required to maintain the kind of legibility and reliability other languages & frameworks can give you "for free".

I expect a Rails project has the best hope of remaining good at a business that's got solid funding for an in-house team from day 1, and has good retention for that team. However, lots of startups or experimental ventures by larger firms experience a lot of thrashing and turnover in the early days, and often go through one or more periods of heavy outsourcing, while also being the kind of resource-constrained enterprise for which Rails is extremely tempting.

Arguably Rails is still the right call for them, if it gets them to market fast, but those kinds of places consistently end up hit with slow, expensive, risky feature development just as they're starting to get traction, much earlier than the usual "eh, needing to replace this will be a good problem to have" phase, and part of that's because Rails falls apart so fast if you color outside the lines at all.

[jack_riminton]

The fact that 8/10 of the top YC alum companies (as of 2019) used Rails would indicate that it isn't the massive liability you portray it to be https://spreecommerce.org/ruby-on-rails-most-popular-among-t...

[tboyd47]

What about Rails causes this problem as opposed to other frameworks?

[trebbble]

It's chiefly difficulty reading & navigating the code due to all the magic (made even worse by dynamic typing), plus reliance on extensive, comprehensive tests to maintain any amount of confidence it's doing what it's supposed to, or even to figure out what it's supposed to be doing. Not that tests aren't handy just about everywhere, but it's a matter of degree of reliance on them and how bad a time you'll have if the test suite's absent, or stale & neglected.

[tboyd47]

I'm sorry you had a bad time with Rails but I don't find this to be a fair assessment. I've done Rails development for about 15 years and worked on over a dozen production codebases.

> "all the magic"

The "magic" factor in RoR is much less than, say, iOS development in XCode. And RoR has the benefit of being text-based, so whatever functionality you're looking for, you can be sure it's in a text file somewhere.

> made even worse by dynamic typing

This is a feature Ruby shares with the #1 and #2 most used programming languages.

> how bad a time you'll have if the test suite's absent, or stale & neglected

I agree that having no tests or bad tests guarantees a bad time, but I'd say it's pretty standard for even the bad codebases to be covered pretty consistently with unit tests. The Rails community has, by and large, accepted unit tests as part of our shared culture, so if your developers adhere to Rails convention, they will maintain decent test overage. That's a strength of RoR, not a weakness.

[trebbble]

> The "magic" factor in RoR is much less than, say, iOS development in XCode. And RoR has the benefit of being text-based, so whatever functionality you're looking for, you can be sure it's in a text file somewhere.

Noooooo. A ton of things simply aren't defined until the program's running. "What even is this?" is frequently a question that's hard to answer without running the project (hope it's in a runnable state, then!)—even figuring out whether something's from Rails or from some other module (which one? Start googling or have fun poking at the Rails console against a running copy of the code until you figure it out) can be a pain. There's far less runtime metaprogramming magic in any other ecosystem I've worked in, which is lots and lots of them (including iOS). It's everywhere in Rails.

[EDIT] Also:

> The Rails community has, by and large, accepted unit tests as part of our shared culture, so if your developers adhere to Rails convention, they will maintain decent test overage. That's a strength of RoR, not a weakness.

Yes, tests are good! A culture of testing is good! But not every language/framework suffers so greatly from absent or bad tests as Rails does. Such heavy dependence on them is not a strength of Rails (though the culture of testing is).

[tboyd47]

> Start googling or have fun poking at the Rails console against a running copy of the code until you figure it out) can be a pain

Funny, none of those things sound bad to me, but just like part of the job :D Could be Stockholm Syndrome?

[trebbble]

It's part of the job with Rails. In many other ecosystems your tools just tell you the answer immediately, or you can at least easily grep your way to an answer.