[bobbytherobot]

Maybe Rails has changed from when I last used it five years ago, but I dealt with many of the issues DHH makes against other technology.

> That people spent hours, if not days, just setting up the skeletons. The basic build configurations.

I spent hours everyday getting the asset pipeline to work, or it would break again, meaning I would have to fix it again.

> The vast majority of activity today is for yet another option on the a la carte menu.

Every week the developers want to switch out some module for another module within Rails because it was the hot new thing.

Maybe I worked on a bad project. Maybe I didn't get it. Maybe it was a growing pain that has passed. Rails was a pain in the ass to get to work. The ORM was cool, but did it save me time or mistakes from writing SQL - no.

I would love other people's opinions who have stuck with Rails.

[armandososa]

For many years I tried to install Rails in my computer and it just refused to play well with the installation of MySQL on my Mac. I looked on SO and tried some CLI commands and configurations that I could barely understand for a couple of hours and then, when nothing worked, I just stopped and went back to CakePHP (which I used to love). I did this like every six months for maybe 5 years and then I became mostly a front end developer and I stopped caring. Nowadays with most of my projects there's somebody providing me with a REST API and I don't care what they are using to generate it.

[enraged_camel]

>>Every week the developers want to switch out some module for another module within Rails because it was the hot new thing.

You misunderstood DHH's point. He's talking about well-integrated defaults. He isn't talking about preventing people from using other modules if they choose to do so.

I mean, if your developers want to try the hot new thing every week, Rails isn't the problem. That much should be obvious.

[deedubaya]

> I spent hours everyday getting the asset pipeline to work, or it would break again, meaning I would have to fix it again.

I used to have this problem too -- more so in the early days of asset pipeline. Mostly when trying to use some client side framework. Rails is working on (or maybe already available, I'm not sure) yarn/webpack support.

> Every week the developers want to switch out some module for another module within Rails because it was the hot new thing.

Replacing the batteries which are included can be painful at times. If you want to use the new hotness in Rails, it comes at a price of extra work getting it working... but it only seems painful when comparing to the included batteries -- they just work. Support for different test frameworks, orms, templating languages are pretty good anymore though and are easier to swap out.

You'll definitely have a better experience with Rails if you forego the desire to run the latest and greatest and just use what Rails already has.

[throwanem]

Until a new point release comes out and everyone forgets about the one you're running. Then you get to find out how much of your code you'll need to rewrite so it'll run with the Rails chefs' wild new menu. And there's no point even trying with an app written for an earlier major version. Just give up now, because the whole ocean's been boiled and recondensed since then, and now occupies but few of the basins it once did.

Granted, it's been a couple years since I dealt with any Rails apps. That's in large part by design, because every Rails app has a relatively high curation cost just to keep it up to date with the latest and greatest, and you have to do that if you want to be able to add features or usefully maintain anything without undue agony, because the Rails community has the collective memory of a goldfish and even less interest in maintaining continuity with the past.

I get that that's the big selling point, the drum DHH and his fans never stop beating: "Rails is omakase." This is a fundamentally broken metaphor, because sushi is dead by the time it gets to you, and all you have to do with it is eat it; the history of the ingredients is of little consequence. Would that software were so simple.

[deedubaya]

> Until a new point release comes out and everyone forgets about the one you're running

This is definitely a pain you'll feel with rails, and any other combination of software pieces which you bring together.

For what it's worth, within the last month, I've touched rails 3.2, 4.0, 4.1, 5.0, and 5.0.1 apps which are running in production. It's possible to maintain these apps on old releases, but the idea of never upgrading will be painful in the end.

[throwanem]

It's worse in Rails because of the rate of change and the near-total lack of interest in backwards compatibility. Granted that the change in question often improves Rails' performance or stability, but that so much scope seems to go on existing for such improvements is in itself concerning, and the larger question, of whether it would be wiser to instead invest in a less volatile and more stable platform, remains valid.

[patsplat]

Many of DHH's complaints are normal parts of every software project:

- depending on third party packages can be a pain

- switching environments / languages is annoying

The argument that these things disappear with Rails is weak.

The historical argument that a dynamically typed language can handle these issues more gracefully than J2EE is valid but less relevant today.