Hacker News Reader

Comment by tboyd47 | Hacker News Reader

The codebase I'm working on now is what I consider an exemplary Ruby on Rails project. It is 14 years old and still going strong. It is structured exactly like you'd expect a Rails project to be structured. The gems the authors chosen have been reliable so far with few exceptions. We regularly step into sections of code that are 5 or even 10 years old, and modify/extend them with no issue. Even brand new programmers (fresh out of boot camp) find it easy to work with. It is a success by all standards of software engineering.

View on HN

Yes. I'm working on an actively developed rails product that is close to 10 years old. All the stuff that just followed the "rails way" is still super easy to work with to this day. All the "experiments" (you find these in any old code base as developers and fads come and go) in "decoupling from rails" or whatever are extremely fragile and difficult to work with.

This applies to almost any programming language - things done "the standard way" will survive decently well (or have obvious migration paths) - things done "your own way" will be more fragile.

Of course, languages vary on how much they have a "standard way" of doing things.

I might get a lot of flame for this, but I would say this is probably true of most Rails project because Rails has a lot of great standards (opinions). I am not sure why people hate Rails, I love it exactly for this reason.

Personally I think the key is the code by convention mentality. This extends an idea used all throughout computing -- abstraction. The fact that you don't need to look at exactly how it's done, but can work with a generalized model with excellent results (albeit not necessarily perfectly optimal).

IMO one kind of "bad code" is code where i need to know about >3 things/places to change 1 thing. Where features get splayed across N places instead of being able to live in their 1 spot + direct consumers.

It's true of any Rails project that adheres to the great standards. :)

Unfortunately many developers think they're more clever than the standards (and as a medium to display their cleverness, they find Ruby quite accommodating)

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.

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

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.

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.

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

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

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.

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

I like Rails a lot and use it for my personal web-based projects. Rails (and Ruby in general) is (/are) great because of strong convention, as you mentioned.

But I would say that the danger is that you can break rules in bizarre unpredictable ways, which I've done myself and then gone WTF when going back to those projects years later.

It's also kind of annoying to set up and upgrade, lots of middleware to manage, but that's the case for almost every framework.

Same here. But the one I'm using is 7 years old. Very nice code, some opportunities here and there, of course.

I always mention this when I'm hiring: our codebase is "old", but the code is actually well written and tested. I've seen worse code in projects that are just a couple of months old.

Same here. Knew nothing about Ruby before, the cleanliness and ease of deployment and database migrations/rollbacks with capistrano and rake made a great impression!

> It is 14 years old

Curious - what version of Rails is it running on?

When I joined, it was Rails 4. Since I've been there, we upgraded to 5 and are now about to start migrating to 6.

A traditional rails structure does not age well. It must be a nightmare for any new hire to understand the domain and boundaries.

Except that GP says it has aged well and isn't a nightmare.

Reply on news.ycombinator.com