6 ms·
tl;dr: "Rails: Not even once." Everything in Rails is so much work because Rails is a rolling disaster; every new major version replaces enormous chunks of fra
by aaronem 13y ago
tl;dr: "Rails: Not even once."
Everything in Rails is so much work because Rails is a rolling disaster; every new major version replaces enormous chunks of framework functionality with enormous new chunks of functionality, which imposes a heavy load on the developer; "convention over configuration", plus major changes to the convention du jour in every major version, equals a necessity to re-learn, at every major version change, where the new magic lurks and precisely how it works. If I'm being entirely fair, I can't say that the Rails developers have no interest in backwards compatibility, but such interest in my experience is both quite spotty and heavily concentrated on obvious and conventional behavior, which means anything non-obvious or unconventional is probably going to need heavy rework. (I have yet to run across a Rails app which did not, at least occasionally, do something non-obvious or unconventional, and necessarily so; no framework can cover every use case, but Rails in particular seems interested in covering only the most common ca. 60%.)
To make matters worse, no one in the Rails community has the slightest interest in yesterday, and even today tends to be neglected in favor of tomorrow. You talk of entire books on the subject of Rails deployment, and while the necessity for such books to exist is certainly a problem, actually having such a book means you're doing better than average; I've recently been fighting my way through an upgrade of a Rails 2.3 app to run under Rails 3.2; it's a difficult enough task to begin with, and is massively complicated by the fact that no real documentation exists on how to perform such an upgrade. What's there is mostly to be found on various Rails devs' Tumblrs, or in IRC logs or commit comments, and these are both poorly curated and evanescent; I've spent quite as much time trying to collate information on how to perform this project as I have actually editing code, and if not for the Internet Archive, a couple of critical Tumblr posts would no longer be available at all, thanks to the Rails dev who wrote them having apparently decided to "reboot" his blog.
The whole process has been enormously frustrating, not to mention slow; I started this project better than six months ago, as a novice Rails developer, and I'm just now getting to a point where I can see the light at the end of the tunnel. I am also strongly convinced that Rails is never the right solution; as long as I'm employed at this organization, it will embark upon a new Rails project only over my metaphorical smoking corpse. There's just too much to go wrong, and the underlying ideas of the Rails community are too wrong-headed to make for a reliable platform; the purpose of a framework is to free the developer from having to rearchitect the same infrastructure over and over, yet Rails not only forces developers to do so during upgrades, but the massive changes to core functionality I mentioned earlier make the rearchitecting task enormously more complicated and painful than it'd be in the absence of any framework at all -- I do not engage in hyperbole when I say that I've led upgrades from PHP 4 to PHP 5 which were both less painful and more quickly completed than the task of upgrading a single, rather small, site, from Rails 2.3 to Rails 3.2 has been.
Rails, overall, is the worst example I've ever seen of the development model which Zawinski calls "CADT" [1]; between that, and the deep-seated and dangerous problems Shaw identifies with the Rails community as a whole [2], anyone other than a Rails core developer, who involves Rails in a project of any sort save perhaps a tiny single-developer throwaway prototype, is borrowing trouble on a potentially catastrophic scale both for himself and for any unwitting organization on which he chooses to inflict the resulting disaster.
[1] http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html
[2] http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto
- hawleyal 13y agoFUD
- aaronem 13y agoWhy bother to respond at all if you're not going to put forth even a minimal effort?
- zpe 13y ago"no one in the Rails community has the slightest interest in yesterday" I think this is pretty disrespectful. The deprecation warnings and online documentation didn't magically appear. For example this section "upgrading to 3.2" from the official docs: http://guides.rubyonrails.org/3_2_release_notes.html#upgrading-to-rails-3-2 http://guides.rubyonrails.org/3_2_release_notes.html#upgradi... I'm personally very thankful for all of the hard work the community has done to help us upgrade. If you have found pieces of the upgrading puzzle that are missing, then please consider contributing back. 2.3 > 3 is the hardest one. It gets a lot easier.
- aaronem 13y agoThat's not much of an example; to say that it barely scratches the surface, in all its seven-paragraph glory, is to be if anything excessively kind. This is unfortunately typical of the Rails community's attitude toward these matters; you may safely assume that, were there anything remotely resembling sufficient documentation available, I would not feel the need to utter complaints such as those above -- if I have anywhere given the erroneous impression that I enjoy hacking my way through this horrible triple-canopy jungle, without so much as a sketch map, please allow me at this juncture to disabuse you of the notion!
- zpe 13y agoI have no knowledge as to what you think of triple canapés, but I do get a strong feeling of entitlement from you. You also seem to disregard a whole bunch of people(like me for example) that didn't experience as much pain as you. As well as the people that have dedicated their time to write deprecation warnings and documentation, recording videos etc.. Worst case, your app is exceptionally hard to upgrade and I feel for your effort.