18 ms·

There are several "we upgraded Rails, it was huge, risky, and took months to years" blog posts from medium to large companies. I personally take this as a warni

There are several "we upgraded Rails, it was huge, risky, and took months to years" blog posts from medium to large companies. I personally take this as a warning against using Rails. Ruby is one of the most dangerous dynamic languages to refactor, I don't see how struggling to do it for over a year is a selling point of the framework. It also feels counter to Rails's mantra of delivering value fast with little effort, until you need to upgrade, then you have months of no business value delivery and need to bring in experts to help.

throwaway427 8y ago
Much of your comment history is hijacking HN threads to complain about Ruby and Rails. Not sure what terrible things you've seen in your days as a Ruby programmer, but it might be worth it to try and talk to someone about it and get it out and learn to deal with your trauma.
- techntoke 8y ago
  Sometimes the truth is hard to accept
- dang 8y ago
  Personal attacks will get you banned here. Please don't do this again. If you think someone is using HN abusively, you should email us at hn@ycombinator.com so we can investigate. Attacking them in the comments is not cool, and being personally nasty is of course a bannable offense. If you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here, we'd be grateful.
majewsky 8y ago
> Ruby is one of the most dangerous dynamic languages to refactor A thousand times this. It's so much easier to do breaking changes and refactors in a language that's supporting you, instead of working against you.
- cknoxrun 8y ago
  Dynamic language or not, having good test coverage will be your biggest support.
  - weberc2 8y ago
    It's definitely important, but we (Python shop) have "good" (85%) test coverage and we still see 500s in prod every day because of things a type checker could trivially catch. And this is just in the course of normal operation; this isn't even a migration. Having extensive experience with both Go and Python, I would conservatively estimate that Go requires ~30% fewer tests than untyped Python for the same confidence. That's more than 30% time savings; not only are you not writing 30% of the tests, but that's 30% fewer tests to have to maintain. Of course these aren't the only considerations--for certain tasks Python may be faster to develop with (although I think people forget about things like deployment, tooling, dependency management, performance requirements, etc when they make their estimations).
    - jb3689 8y ago
      I noticed something similar with Elixir with regards to the number of tests we needed thanks to the compiler, but it also has late binding (albeit it is statically typed). A "best of both worlds" exists out there
    - MattHeard 8y ago
      Line coverage is not test coverage. Having a test execute every line in your application doesn't mean your application is _covered_ or _tested_.
      - weberc2 8y ago
        Yes, we all know the metric is easily gamed but no one at our org is trying to game the metric. We are paid to build a product, not to boost the metric.
        8y ago
tjpnz 8y ago
It depends on where you're coming from. Going to Rails 3.2 from a previous version is painful but upgrading from 3 to 4 or even 5 is considerably less dangerous.
paulddraper 8y ago
I agree with everything you said, but know that upgrading platforms is not a pain unique to Rails. How long was AWS Lambda not able to support Python 3? How long was GCP not able to support Java 7? How hard is it to upgrade any core framework or language?
- uranusjr 8y ago
  I feel this is comparing apples to oranges. Computing platforms supporting a new runtime is less about porting existing code, but more like adding a new feature to the code base. You really don’t see much “we port our app from framework/language version X to Y” articles anywhere, except for maybe Python 2/3. But that only generally happen for one version bump for a long time. Ruby (and particularly Rails) is really not doing as well as some of other players in this area.
  - paulddraper 8y ago
    Django is a great product. But migrate a large project between versions multiple years apart, and you'll feel it.
mberning 8y ago
If they had good test coverage and stayed on top of updates this would be a non issue. Going across several major versions of any language/framework is going to be painful.
quaunaut 8y ago
It didn't take Github as a whole a year to go from 3.2 to 5.2. It took a small team within Github to work with everyone to upgrade from 3.2 to 5.2, with most of the changes introducing business value in the form of security and technical debt fixes(as many issues as I have with Rails, which are many, deprecations aren't willy nilly and generally have great reasoning behind them).
- pknopf 8y ago
  His point still stands. You can find other platforms we're updating is a lot easier. That is the issue.
  - KurtMueller 8y ago
    What other platforms have you updated that was a lot easier?
    - daybreaker2 8y ago
      and at github's scale at that.
  - dylanz 8y ago
    I'd love to know what other frameworks would be easier. It's all relative. I've been involved in upgrades of a lot of statically typed projects, in many languages, and... it's all the same. Major upgrades are always a pain in the ass.
  - titusjohnson 8y ago
    - 10 year old codebase under active development. - 2 major versions and 4 years out of date. - Upgrade started as a half-hearted "in your free time" effort with no official team, or maybe 1 dev (article says both). - Upgrade included "cleaning up technical debt and improving the codebase", (you could define almost any work under that umbrella). - At the end there were only 4 devs full-time on the upgrade. I don't know of any platform that would make the above situation all that much easier...
  - 8y ago
bubblicious 8y ago
I would take that warning with a grain of salt. You're talking about the main underlying framework upgrade from 4 years back to today. Take any MVC framework that powers your entire system with a 4 year upgrade gap and you'll end up with the same type of debt. Also you're measuring effort in "X number of months" but as the article states it started as a hobby side-project for a few engineers. There is no notion of how much effort it actually represented. Heck I could need 5 years to upgrade from angular 1 to angular 2 if I put in 30 secs per day... I would actually advocate for a framework that's past its prime/hype period over any newly untested hyped framework any day.
jfaucett 8y ago
> until you need to upgrade, then you have months of no business value delivery and need to bring... This is not the case in my experience. I've upgraded pretty decent sized apps (hundreds of models,lines of routes, etc) and in my experience it would take a couple hours a day spread out over a few days a month and then I was done (for versions: 3-4 and 4-5, never done 3-5). I would say most of the problem is making sure everyone on the team just keeps all functionality as-is. It can be tempting for team members to refactor as they go through but this then becomes a huge time-sync. Anyways, thats my exp on rails but I have no other frameworks to compare it to. Has anyone migrated a massive app from some PHP Framework like Symfony or from a java framework like Play, or any framework with a large code base? I have had to upgrade massive systems that were not done with any framework and full of one-off solutions with in-house developed libraries and it was an absolute nightmare, but I'm sure this depends on the language and team. However, in general I think an open-source library used by millions or even hundreds of people is going to have better documentation, bug coverage, support, etc. than something done in house, just IMHO. So I guess my question would be, what does the alternative look like?
- cevn 8y ago
  I agree with your post but just wanted to throw out that it's time sink instead of time sync ;) imagine all that time going down the drain!
- thibaut_barrere 8y ago
  My experience looks like yours - in-house frameworks (e.g. typically in banks) are a mess when it comes to upgrading.
drum 8y ago
The problem I have with statements like this are that they apply to every large framework, not just Rails. ASP, Django, Zend, Cocoa etc. A combination of libraries are bound to be hard to update two major versions later when methods and variables are deprecated.
briandear 8y ago
Assuming you have proper test coverage, upgrading even a “big” app isn’t that hard. The problem is when companies neglect the value of automated testing until they actually need it.
danso 8y ago
According to the article, the upgrade took 1 year for 3.2 > 4.2, and then just 5 months for 4.2 > 5.2. The project began with one FTE, and some volunteers, and expanded to 4 FTEs. But the author says almost none of them had ever done a Rails upgrade before. I'm curious to what you think would be a better framework for Github to have used, that would've allowed for easier, speedier point upgrades? Rails likely was a big advantage (as it usually is) in the initial stages. Are you seriously expecting it to be just as smooth when the site experiences exponential user and feature growth? That moving from Rails 3 to 5 was doable, with what sounds like a small team and no massive service disruption, seems like a very strong argument that Rails can still be effective in a company's middle-age years.
- jrs95 8y ago
  ASP.NET MVC as uncool as that might be. IMO this is as close to the benefits of Rails you can get in a statically typed language. And it really doesn't take very long in developing a project for static typing to start saving you time either. IDEs can just be a lot more intelligent with static types, and it can be a big help in the readability of code without fully understanding the broader context. The upgrade to .NET Core is probably worse than a Rails upgrade though, although it's not really the same thing as .NET Framework will continue to be updated for awhile. Switching to Core is really only necessary if running on Linux servers is a big win for you.
  - erokar 8y ago
    > ASP.NET MVC as uncool as that might be. IMO this is as close to the benefits of Rails you can get in a statically typed language. I agree .NET MVC is as close as you get to something like Rails with regards to productivity in a statically typed, enterprisy language. But using .NET/C# at Github would still have ended up with a significantly larger codebase -- which means more code to maintain, and therefore also in all likelyhood more bugs.
  - jermaustin1 8y ago
    Migrating an ASP.Net MVC app from .Net Framework to .Net Core isn't really an upgrade, as both frameworks are continually updated. The migration is a pain, but just upgrading from MVC 4 to 5 wasn't painful. I am sure 2 to 5 would have been a nightmare, especially if you were using the deprecated Microsoft JavaScript libraries, and needed to replace them with their jQuery alternatives.
mjw1007 8y ago
I think it depends on whether "took months to years" means there was a team of several programmers working on it full-time for that period, or whether it just takes a couple of people working on and off and most of the time is waiting to see whether the logs are showing any problems. (And time under the "took the opportunity to clean up technical debt" heading shouldn't really count.)
brightball 8y ago
Fwiw, you’re not wrong but most of those stories are around the actual Ruby jump from 1.8.7 to 1.9.3. It was necessary but painful.
erokar 8y ago
And yet, when Ruby is compared with other languages with regards to bugs in an actual study [1] it does better than many statically typed languages (e.g. Java, C#, Go, Typescript). Add to that that a Ruby code base will be significantly smaller than a codebase in most statically typed languages. That means less code to maintain, and probably fewer bugs. 1. https://www.i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html https://www.i-programmer.info/news/98-languages/11184-which-...
- cix_pkez 8y ago
  This is disingenuous. Quoting the abstract: ``` Language design does have a significant, but modest effect on software quality. Most notably, it does appear that disallowing type confusion is modestly better than allowing it, and among functional languages, static typing is also somewhat better than dynamic typing. We also find that functional languages are somewhat better than procedural languages. ``` The "statically typed" languages that you're focusing on (I say probably because they're the ones with high bug counts in the data) are probably C and C++, which have other issues making them higher in bug count. C is hardly even typed. Both have manual memory management. Also, there's no control for commit frequency. Some people put everything in one commit, while others commit every line change. The Rails Tutorial even recommends the latter. Lastly, Scala and Haskell killed in this study, as far as raw numbers go. But it doesn't seem significant. I'll stick with subjective evaluations for now. This is just too hard to measure.
  - erokar 8y ago
    I am simply referring to the result data from the study. I fail to see how that is disingenuous. You say Scala and Haskell killed it in the study, and you are right, they were the third and second best language respectively with regards to low rates of bugs. Perhaps you also happened to notice (but failed to mention) what language did best of all: Clojure, a dynamically typed language.
    - cix_pkez 8y ago
      I leave it to future readers to decide who's missing the point between the two of us.
true_religion 8y ago
Some people are still using Java 1.5 so I do not see how being a static language means you will find it easy to upgrade.
- nv-vn 8y ago
  If you miss something, the language shouldn't let it compile. Obviously the more backwards compatibility a language desires, the less likely this is to happen.
- TheDong 8y ago
  Your comment is fallacious in several ways: 1. You're citing a specific anecdote (some people... java1.5) and trying to generalize. What matters is not some people, but the average case, which "some people" will not tell you. 2. "easy to upgrade" is not being argued; "easier in general" is. Just because it's easier to upgrade in a statically typed language doesn't make it easy, just easier than for a dynamically typed one. In effect, you're saying "there are people using statically typed languages who didn't update, so it must not be easy to update". A statement that makes a similar fallacious jump is: "There are some people who still type slowly on computers so I can't see how anyone could claim typing on computers is generally faster than typing on typewriters". Anyway, the fact that the compiler catches more errors at compile-time means it should be obvious that it's easier to upgrade a statically typed language. If I have a method in ruby "user.get_id" which used to return an int, but now returns a uuid in a new version of the framework, for a statically typed language my code just won't compile on the new framework until I handle that, regardless of test coverage... where-as in ruby, I'll need to have test coverage of that path or read the upgrade notes or something. There are valid arguments to be had about dynamic vs static typing, but whether it's safer/easier to perform an upgrade of a library/framework is not an argument that dynamic typing can win easily.
_acco 8y ago
Or perhaps it’s survivorship bias. Companies that used Rails are around today with big, dated codebases because Rails adequately served the needs of their growing businesses.
elliotlarson 8y ago
I think you're throwing the baby out with the bathwater here. GitHub has an enormous codebase where they've done a lot of work digging around in and modifying Rails under the hood. I think their situation calls for it and they have the internal talent to successfully "go off the rails" a bit. But it makes the upgrade path difficult. This is par for the course. Can you think of a technology/framework that would fare better than Rails in this case? I mean, you'd be in the same boat with Django, Spring, [your framework of choice], right?
- TheDong 8y ago
  You would not be in the same boat in a dependently typed language. In such a language, any change on framework update would cause compiler errors if the framework's type constraints didn't match what your code expected. As a result, upgrading in a dependently typed language is simply a matter of fixing compiler errors, and then it's upgraded. For non-dependently-typed languages that take advantage of the type system, it's still significantly easier, though you probably will have to do a little more than just make sure it compiles.
  - erokar 8y ago
    Maybe, but what dependently typed language has the stability, documentation, framework and overall development ergonomics that would let you create something like Github with the resources and the time they did?
  - JohnBooty 8y ago
    > As a result, upgrading in a dependently typed > language is simply a matter of fixing compiler > errors, and then it's upgraded. This is very naive, and is probably hilarious to a lot of people who've been through upgrade hell in a dependently typed language. A few (and then some) major reasons: 1. It's really the subtle runtime behavior changes that bite you. The ones that a compiler doesn't help you with. (This is not a Rails-specific thing; ask Unity or OpenGL etc. devs) 2. A lot of the pain of upgrading a project (Rails or otherwise) is dependency hell. You upgrade the framework, but some of your dependencies haven't been updated and don't work with the newer framework version. This is true whether it's a dynamic or compiled app. 3. It's certainly true that in a strongly typed language, these sorts of trivial problems would be caught at compile time and that's certainly an advantage. However it's not exactly rocket science to catch these in a Rails app. Assuming your test suite is anywhere near adequate, it's going to spit out a comprehensive list of these problems just like a compiler would, albiet not as instantly. 3a. Rails is pretty good about documenting these breaking identifier changes between versions. They don't exactly sneak up on you, unless you get drunk one night and decide to upgrade your enterprise Rails app without looking at the release notes. 3c. Rails is also quite conscientious at loudly announcing to you, via log messages, when you use functionality that is deprecated and targeted for removal. Assuming you're not willfully ignoring these (ie, drunken late-night upgrade bender?) they don't typically catch one by surprise.
samgranieri 8y ago
You can refactor with confidence in Ruby if you have a good test suite. Just do it incrementally and test it well along the way, and also (when using Rails) address any deprecation notices you find along the way and you'll be fine. I've been using Rails since late 2005, and in my last job upgrades a few Rails apps that haven't been touched since 2008 or so.
JohnBooty 8y ago
I can't agree with you. Can you name a framework where upgrading a very large (several hundred thousand LOC or more) application across 6+ years, two major versions, and multiple minor versions is not a significant undertaking? FWIW at my former employer we had a huge Rails monolith with something like 500K+ lines of code. On top of that, our genius architects had split it up into a very nonstandard Rails architecture. We hired these folks (no affiliation, other than that I used to work for a company that hired them) and they did a solid job. They blogged fairly extensively about each incremental upgrade and the problems they encountered: https://www.ombulabs.com/blog/tags/upgrades https://www.ombulabs.com/blog/tags/upgrades Do you see anything there that's much more painful than a similarly ambitious upgrade in other frameworks?
- groestl 8y ago
  We had that experience with Spring, which was pretty painless. One FTE, 3 weeks, ~1/2 mio LOC, and included a Java major version bump.
thibaut_barrere 8y ago
I use Rails, but also Elixir, and in the past Java, .Net, and many other tech stacks. In my experience all large or very large scale apps upgrades (and I've done quite a few) are complicated in a way or another, no matter the stack. Technical debt stacks up in subtle ways (dependencies get obsolete, a specific feature used the framework in unusual ways, stuff can be rewritten with more built-in framework features etc). I don't see how this article would give Rails bad publicity, personally; I'll add that the advice they provide is pretty much what I would recommend for any tech stack too.
- nambit 8y ago
  I've done upgrades on absolutely massive codebases for java to JDK7 and JDK8 and have never had anything but minor issues. Very rarely does something break backwards compatibility.
  - thibaut_barrere 8y ago
    Well, I've upgraded an app from Struts 1 to Struts 2 and I don't want to do it again :-) - https://www.infoq.com/articles/converting-struts-2-part1 https://www.infoq.com/articles/converting-struts-2-part1 - https://www.infoq.com/articles/migrating-struts-2-part2 https://www.infoq.com/articles/migrating-struts-2-part2 - https://www.infoq.com/articles/migrating-struts-2-part3 https://www.infoq.com/articles/migrating-struts-2-part3 Granted, the "upgrading" situation has improved since then in the Java world, but it hasn't been always super nice in the past.
  - callumjones 8y ago
    I'm not sure if you can compare upgrading a VM/platform that is usually designed for backwards compatibility to upgrading a framework.
scient 8y ago
I've done major upgrades from 3.2 to 4.1/4.2, and from there to 5.1 followed by 5.2 - the only time we had to put in a little work was when moving from 3 to 4. When moving from 4 to 5, we relied on simple smoke tests and unit tests, and had no major issues or bugs. The biggest effort was to make sure all of the application and environment configurations were up to date and using all the new settings introduced etc. My very subjective opinion is that either most of these code bases are low on quality (meaning they are harder to maintain in general), too tightly coupled with Rails itself (models stuffed full of logic, instead of using plain ruby objects for logic and keeping ActiveRecord for persistence level logic), or engineers are just too scared to make changes to the codebase - which again is perhaps a combination of bad test coverage and bad code quality. Either way the stories of upgrading major versions being a huge undertaking always make me scratch my head and wonder what are we doing wrong if its easy for us. And inb4 someone claims our apps are just small and simple - we run about 12 Rails applications in production in various sizes, about half of them being relatively large.
nateberkopec 8y ago
Let me get this straight: you're arguing that a 10-year-old top-100-in-the-world website taking 4 full-time engineers and having them upgrade their core framework 2 major version over 18 months is some sort of massive failure, and that failure would be solved with static types? Also, you're saying that Github hasn't added any new features in the last 18 months?
- bsansouci 8y ago
  React 16 was a perfectly smooth upgrade for a massive part of the web ecosystem. It took 1 engineer to bump the version number and to test. Maybe a week or two at most to check that nothing was broken.
  - mcintyre1994 8y ago
    The React core team update tens of thousands of Facebook's components every time they update, I expect they'll continue to have uniquely smooth upgrades while that's the case.
- sidlls 8y ago
  Yes, four FTE engineers taking 18 months to upgrade across two major versions indicates a massive problem, but not necessarily with Rails or Ruby. That's a cost of $1.5M give or take, just on the engineers, not including the opportunity cost in new feature development or paying other equally important tech debt.
  - mikemotherwell 8y ago
    $7 billion dollar company, $1.5M cost? $7 BILLION. Your order of magnitudes are waaaaayyyyy off. This is the inverse of survivor bias, in that you are retroactively applying "best practice" at the wrong scale. What gets you from $0 to $7B may hurt you at $7B. Heck, may hurt you way earlier than that. However, and YMMV on what problem you want to solve, but saving $1.5M, heck lets 10X it and call it $15M, saving $15M when worth $7B isn't the problem I'd personally be concerned with.
- 8y ago
Mc_Big_G 8y ago
Oh please. Upgrading any framework is always a huge pain in the ass. Using it as an excuse not to use rails is just that: an excuse.

throwaway427 8y ago

Much of your comment history is hijacking HN threads to complain about Ruby and Rails. Not sure what terrible things you've seen in your days as a Ruby programmer, but it might be worth it to try and talk to someone about it and get it out and learn to deal with your trauma.

techntoke 8y ago
Sometimes the truth is hard to accept
dang 8y ago
Personal attacks will get you banned here. Please don't do this again. If you think someone is using HN abusively, you should email us at hn@ycombinator.com so we can investigate. Attacking them in the comments is not cool, and being personally nasty is of course a bannable offense. If you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here, we'd be grateful.

majewsky 8y ago

> Ruby is one of the most dangerous dynamic languages to refactor A thousand times this. It's so much easier to do breaking changes and refactors in a language that's supporting you, instead of working against you.

cknoxrun 8y ago
Dynamic language or not, having good test coverage will be your biggest support.
- weberc2 8y ago
  It's definitely important, but we (Python shop) have "good" (85%) test coverage and we still see 500s in prod every day because of things a type checker could trivially catch. And this is just in the course of normal operation; this isn't even a migration. Having extensive experience with both Go and Python, I would conservatively estimate that Go requires ~30% fewer tests than untyped Python for the same confidence. That's more than 30% time savings; not only are you not writing 30% of the tests, but that's 30% fewer tests to have to maintain. Of course these aren't the only considerations--for certain tasks Python may be faster to develop with (although I think people forget about things like deployment, tooling, dependency management, performance requirements, etc when they make their estimations).
  - jb3689 8y ago
    I noticed something similar with Elixir with regards to the number of tests we needed thanks to the compiler, but it also has late binding (albeit it is statically typed). A "best of both worlds" exists out there
  - MattHeard 8y ago
    Line coverage is not test coverage. Having a test execute every line in your application doesn't mean your application is _covered_ or _tested_.
    - weberc2 8y ago
      Yes, we all know the metric is easily gamed but no one at our org is trying to game the metric. We are paid to build a product, not to boost the metric.
      - 8y ago

tjpnz 8y ago

It depends on where you're coming from. Going to Rails 3.2 from a previous version is painful but upgrading from 3 to 4 or even 5 is considerably less dangerous.

paulddraper 8y ago

I agree with everything you said, but know that upgrading platforms is not a pain unique to Rails. How long was AWS Lambda not able to support Python 3? How long was GCP not able to support Java 7? How hard is it to upgrade any core framework or language?

uranusjr 8y ago
I feel this is comparing apples to oranges. Computing platforms supporting a new runtime is less about porting existing code, but more like adding a new feature to the code base. You really don’t see much “we port our app from framework/language version X to Y” articles anywhere, except for maybe Python 2/3. But that only generally happen for one version bump for a long time. Ruby (and particularly Rails) is really not doing as well as some of other players in this area.
- paulddraper 8y ago
  Django is a great product. But migrate a large project between versions multiple years apart, and you'll feel it.

mberning 8y ago

If they had good test coverage and stayed on top of updates this would be a non issue. Going across several major versions of any language/framework is going to be painful.

quaunaut 8y ago

It didn't take Github as a whole a year to go from 3.2 to 5.2. It took a small team within Github to work with everyone to upgrade from 3.2 to 5.2, with most of the changes introducing business value in the form of security and technical debt fixes(as many issues as I have with Rails, which are many, deprecations aren't willy nilly and generally have great reasoning behind them).

pknopf 8y ago
His point still stands. You can find other platforms we're updating is a lot easier. That is the issue.
- KurtMueller 8y ago
  What other platforms have you updated that was a lot easier?
  - daybreaker2 8y ago
    and at github's scale at that.
- dylanz 8y ago
  I'd love to know what other frameworks would be easier. It's all relative. I've been involved in upgrades of a lot of statically typed projects, in many languages, and... it's all the same. Major upgrades are always a pain in the ass.
- titusjohnson 8y ago
  - 10 year old codebase under active development. - 2 major versions and 4 years out of date. - Upgrade started as a half-hearted "in your free time" effort with no official team, or maybe 1 dev (article says both). - Upgrade included "cleaning up technical debt and improving the codebase", (you could define almost any work under that umbrella). - At the end there were only 4 devs full-time on the upgrade. I don't know of any platform that would make the above situation all that much easier...
- 8y ago

bubblicious 8y ago

I would take that warning with a grain of salt. You're talking about the main underlying framework upgrade from 4 years back to today. Take any MVC framework that powers your entire system with a 4 year upgrade gap and you'll end up with the same type of debt. Also you're measuring effort in "X number of months" but as the article states it started as a hobby side-project for a few engineers. There is no notion of how much effort it actually represented. Heck I could need 5 years to upgrade from angular 1 to angular 2 if I put in 30 secs per day... I would actually advocate for a framework that's past its prime/hype period over any newly untested hyped framework any day.

jfaucett 8y ago

> until you need to upgrade, then you have months of no business value delivery and need to bring... This is not the case in my experience. I've upgraded pretty decent sized apps (hundreds of models,lines of routes, etc) and in my experience it would take a couple hours a day spread out over a few days a month and then I was done (for versions: 3-4 and 4-5, never done 3-5). I would say most of the problem is making sure everyone on the team just keeps all functionality as-is. It can be tempting for team members to refactor as they go through but this then becomes a huge time-sync. Anyways, thats my exp on rails but I have no other frameworks to compare it to. Has anyone migrated a massive app from some PHP Framework like Symfony or from a java framework like Play, or any framework with a large code base? I have had to upgrade massive systems that were not done with any framework and full of one-off solutions with in-house developed libraries and it was an absolute nightmare, but I'm sure this depends on the language and team. However, in general I think an open-source library used by millions or even hundreds of people is going to have better documentation, bug coverage, support, etc. than something done in house, just IMHO. So I guess my question would be, what does the alternative look like?

cevn 8y ago
I agree with your post but just wanted to throw out that it's time sink instead of time sync ;) imagine all that time going down the drain!
thibaut_barrere 8y ago
My experience looks like yours - in-house frameworks (e.g. typically in banks) are a mess when it comes to upgrading.

drum 8y ago

The problem I have with statements like this are that they apply to every large framework, not just Rails. ASP, Django, Zend, Cocoa etc. A combination of libraries are bound to be hard to update two major versions later when methods and variables are deprecated.

briandear 8y ago

Assuming you have proper test coverage, upgrading even a “big” app isn’t that hard. The problem is when companies neglect the value of automated testing until they actually need it.

danso 8y ago

According to the article, the upgrade took 1 year for 3.2 > 4.2, and then just 5 months for 4.2 > 5.2. The project began with one FTE, and some volunteers, and expanded to 4 FTEs. But the author says almost none of them had ever done a Rails upgrade before. I'm curious to what you think would be a better framework for Github to have used, that would've allowed for easier, speedier point upgrades? Rails likely was a big advantage (as it usually is) in the initial stages. Are you seriously expecting it to be just as smooth when the site experiences exponential user and feature growth? That moving from Rails 3 to 5 was doable, with what sounds like a small team and no massive service disruption, seems like a very strong argument that Rails can still be effective in a company's middle-age years.

jrs95 8y ago
ASP.NET MVC as uncool as that might be. IMO this is as close to the benefits of Rails you can get in a statically typed language. And it really doesn't take very long in developing a project for static typing to start saving you time either. IDEs can just be a lot more intelligent with static types, and it can be a big help in the readability of code without fully understanding the broader context. The upgrade to .NET Core is probably worse than a Rails upgrade though, although it's not really the same thing as .NET Framework will continue to be updated for awhile. Switching to Core is really only necessary if running on Linux servers is a big win for you.
- erokar 8y ago
  > ASP.NET MVC as uncool as that might be. IMO this is as close to the benefits of Rails you can get in a statically typed language. I agree .NET MVC is as close as you get to something like Rails with regards to productivity in a statically typed, enterprisy language. But using .NET/C# at Github would still have ended up with a significantly larger codebase -- which means more code to maintain, and therefore also in all likelyhood more bugs.
- jermaustin1 8y ago
  Migrating an ASP.Net MVC app from .Net Framework to .Net Core isn't really an upgrade, as both frameworks are continually updated. The migration is a pain, but just upgrading from MVC 4 to 5 wasn't painful. I am sure 2 to 5 would have been a nightmare, especially if you were using the deprecated Microsoft JavaScript libraries, and needed to replace them with their jQuery alternatives.

mjw1007 8y ago

I think it depends on whether "took months to years" means there was a team of several programmers working on it full-time for that period, or whether it just takes a couple of people working on and off and most of the time is waiting to see whether the logs are showing any problems. (And time under the "took the opportunity to clean up technical debt" heading shouldn't really count.)

brightball 8y ago

Fwiw, you’re not wrong but most of those stories are around the actual Ruby jump from 1.8.7 to 1.9.3. It was necessary but painful.

erokar 8y ago

And yet, when Ruby is compared with other languages with regards to bugs in an actual study [1] it does better than many statically typed languages (e.g. Java, C#, Go, Typescript). Add to that that a Ruby code base will be significantly smaller than a codebase in most statically typed languages. That means less code to maintain, and probably fewer bugs. 1. https://www.i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html https://www.i-programmer.info/news/98-languages/11184-which-...

cix_pkez 8y ago
This is disingenuous. Quoting the abstract: ``` Language design does have a significant, but modest effect on software quality. Most notably, it does appear that disallowing type confusion is modestly better than allowing it, and among functional languages, static typing is also somewhat better than dynamic typing. We also find that functional languages are somewhat better than procedural languages. ``` The "statically typed" languages that you're focusing on (I say probably because they're the ones with high bug counts in the data) are probably C and C++, which have other issues making them higher in bug count. C is hardly even typed. Both have manual memory management. Also, there's no control for commit frequency. Some people put everything in one commit, while others commit every line change. The Rails Tutorial even recommends the latter. Lastly, Scala and Haskell killed in this study, as far as raw numbers go. But it doesn't seem significant. I'll stick with subjective evaluations for now. This is just too hard to measure.
- erokar 8y ago
  I am simply referring to the result data from the study. I fail to see how that is disingenuous. You say Scala and Haskell killed it in the study, and you are right, they were the third and second best language respectively with regards to low rates of bugs. Perhaps you also happened to notice (but failed to mention) what language did best of all: Clojure, a dynamically typed language.
  - cix_pkez 8y ago
    I leave it to future readers to decide who's missing the point between the two of us.

true_religion 8y ago

Some people are still using Java 1.5 so I do not see how being a static language means you will find it easy to upgrade.

nv-vn 8y ago
If you miss something, the language shouldn't let it compile. Obviously the more backwards compatibility a language desires, the less likely this is to happen.
TheDong 8y ago
Your comment is fallacious in several ways: 1. You're citing a specific anecdote (some people... java1.5) and trying to generalize. What matters is not some people, but the average case, which "some people" will not tell you. 2. "easy to upgrade" is not being argued; "easier in general" is. Just because it's easier to upgrade in a statically typed language doesn't make it easy, just easier than for a dynamically typed one. In effect, you're saying "there are people using statically typed languages who didn't update, so it must not be easy to update". A statement that makes a similar fallacious jump is: "There are some people who still type slowly on computers so I can't see how anyone could claim typing on computers is generally faster than typing on typewriters". Anyway, the fact that the compiler catches more errors at compile-time means it should be obvious that it's easier to upgrade a statically typed language. If I have a method in ruby "user.get_id" which used to return an int, but now returns a uuid in a new version of the framework, for a statically typed language my code just won't compile on the new framework until I handle that, regardless of test coverage... where-as in ruby, I'll need to have test coverage of that path or read the upgrade notes or something. There are valid arguments to be had about dynamic vs static typing, but whether it's safer/easier to perform an upgrade of a library/framework is not an argument that dynamic typing can win easily.

_acco 8y ago

Or perhaps it’s survivorship bias. Companies that used Rails are around today with big, dated codebases because Rails adequately served the needs of their growing businesses.

elliotlarson 8y ago

I think you're throwing the baby out with the bathwater here. GitHub has an enormous codebase where they've done a lot of work digging around in and modifying Rails under the hood. I think their situation calls for it and they have the internal talent to successfully "go off the rails" a bit. But it makes the upgrade path difficult. This is par for the course. Can you think of a technology/framework that would fare better than Rails in this case? I mean, you'd be in the same boat with Django, Spring, [your framework of choice], right?

TheDong 8y ago
You would not be in the same boat in a dependently typed language. In such a language, any change on framework update would cause compiler errors if the framework's type constraints didn't match what your code expected. As a result, upgrading in a dependently typed language is simply a matter of fixing compiler errors, and then it's upgraded. For non-dependently-typed languages that take advantage of the type system, it's still significantly easier, though you probably will have to do a little more than just make sure it compiles.
- erokar 8y ago
  Maybe, but what dependently typed language has the stability, documentation, framework and overall development ergonomics that would let you create something like Github with the resources and the time they did?
- JohnBooty 8y ago
  > As a result, upgrading in a dependently typed > language is simply a matter of fixing compiler > errors, and then it's upgraded. This is very naive, and is probably hilarious to a lot of people who've been through upgrade hell in a dependently typed language. A few (and then some) major reasons: 1. It's really the subtle runtime behavior changes that bite you. The ones that a compiler doesn't help you with. (This is not a Rails-specific thing; ask Unity or OpenGL etc. devs) 2. A lot of the pain of upgrading a project (Rails or otherwise) is dependency hell. You upgrade the framework, but some of your dependencies haven't been updated and don't work with the newer framework version. This is true whether it's a dynamic or compiled app. 3. It's certainly true that in a strongly typed language, these sorts of trivial problems would be caught at compile time and that's certainly an advantage. However it's not exactly rocket science to catch these in a Rails app. Assuming your test suite is anywhere near adequate, it's going to spit out a comprehensive list of these problems just like a compiler would, albiet not as instantly. 3a. Rails is pretty good about documenting these breaking identifier changes between versions. They don't exactly sneak up on you, unless you get drunk one night and decide to upgrade your enterprise Rails app without looking at the release notes. 3c. Rails is also quite conscientious at loudly announcing to you, via log messages, when you use functionality that is deprecated and targeted for removal. Assuming you're not willfully ignoring these (ie, drunken late-night upgrade bender?) they don't typically catch one by surprise.

samgranieri 8y ago

You can refactor with confidence in Ruby if you have a good test suite. Just do it incrementally and test it well along the way, and also (when using Rails) address any deprecation notices you find along the way and you'll be fine. I've been using Rails since late 2005, and in my last job upgrades a few Rails apps that haven't been touched since 2008 or so.

JohnBooty 8y ago

I can't agree with you. Can you name a framework where upgrading a very large (several hundred thousand LOC or more) application across 6+ years, two major versions, and multiple minor versions is not a significant undertaking? FWIW at my former employer we had a huge Rails monolith with something like 500K+ lines of code. On top of that, our genius architects had split it up into a very nonstandard Rails architecture. We hired these folks (no affiliation, other than that I used to work for a company that hired them) and they did a solid job. They blogged fairly extensively about each incremental upgrade and the problems they encountered: https://www.ombulabs.com/blog/tags/upgrades https://www.ombulabs.com/blog/tags/upgrades Do you see anything there that's much more painful than a similarly ambitious upgrade in other frameworks?

groestl 8y ago
We had that experience with Spring, which was pretty painless. One FTE, 3 weeks, ~1/2 mio LOC, and included a Java major version bump.

thibaut_barrere 8y ago

I use Rails, but also Elixir, and in the past Java, .Net, and many other tech stacks. In my experience all large or very large scale apps upgrades (and I've done quite a few) are complicated in a way or another, no matter the stack. Technical debt stacks up in subtle ways (dependencies get obsolete, a specific feature used the framework in unusual ways, stuff can be rewritten with more built-in framework features etc). I don't see how this article would give Rails bad publicity, personally; I'll add that the advice they provide is pretty much what I would recommend for any tech stack too.

nambit 8y ago
I've done upgrades on absolutely massive codebases for java to JDK7 and JDK8 and have never had anything but minor issues. Very rarely does something break backwards compatibility.
- thibaut_barrere 8y ago
  Well, I've upgraded an app from Struts 1 to Struts 2 and I don't want to do it again :-) - https://www.infoq.com/articles/converting-struts-2-part1 https://www.infoq.com/articles/converting-struts-2-part1 - https://www.infoq.com/articles/migrating-struts-2-part2 https://www.infoq.com/articles/migrating-struts-2-part2 - https://www.infoq.com/articles/migrating-struts-2-part3 https://www.infoq.com/articles/migrating-struts-2-part3 Granted, the "upgrading" situation has improved since then in the Java world, but it hasn't been always super nice in the past.
- callumjones 8y ago
  I'm not sure if you can compare upgrading a VM/platform that is usually designed for backwards compatibility to upgrading a framework.

scient 8y ago

I've done major upgrades from 3.2 to 4.1/4.2, and from there to 5.1 followed by 5.2 - the only time we had to put in a little work was when moving from 3 to 4. When moving from 4 to 5, we relied on simple smoke tests and unit tests, and had no major issues or bugs. The biggest effort was to make sure all of the application and environment configurations were up to date and using all the new settings introduced etc. My very subjective opinion is that either most of these code bases are low on quality (meaning they are harder to maintain in general), too tightly coupled with Rails itself (models stuffed full of logic, instead of using plain ruby objects for logic and keeping ActiveRecord for persistence level logic), or engineers are just too scared to make changes to the codebase - which again is perhaps a combination of bad test coverage and bad code quality. Either way the stories of upgrading major versions being a huge undertaking always make me scratch my head and wonder what are we doing wrong if its easy for us. And inb4 someone claims our apps are just small and simple - we run about 12 Rails applications in production in various sizes, about half of them being relatively large.

nateberkopec 8y ago

Let me get this straight: you're arguing that a 10-year-old top-100-in-the-world website taking 4 full-time engineers and having them upgrade their core framework 2 major version over 18 months is some sort of massive failure, and that failure would be solved with static types? Also, you're saying that Github hasn't added any new features in the last 18 months?

bsansouci 8y ago
React 16 was a perfectly smooth upgrade for a massive part of the web ecosystem. It took 1 engineer to bump the version number and to test. Maybe a week or two at most to check that nothing was broken.
- mcintyre1994 8y ago
  The React core team update tens of thousands of Facebook's components every time they update, I expect they'll continue to have uniquely smooth upgrades while that's the case.
sidlls 8y ago
Yes, four FTE engineers taking 18 months to upgrade across two major versions indicates a massive problem, but not necessarily with Rails or Ruby. That's a cost of $1.5M give or take, just on the engineers, not including the opportunity cost in new feature development or paying other equally important tech debt.
- mikemotherwell 8y ago
  $7 billion dollar company, $1.5M cost? $7 BILLION. Your order of magnitudes are waaaaayyyyy off. This is the inverse of survivor bias, in that you are retroactively applying "best practice" at the wrong scale. What gets you from $0 to $7B may hurt you at $7B. Heck, may hurt you way earlier than that. However, and YMMV on what problem you want to solve, but saving $1.5M, heck lets 10X it and call it $15M, saving $15M when worth $7B isn't the problem I'd personally be concerned with.
8y ago

Mc_Big_G 8y ago

Oh please. Upgrading any framework is always a huge pain in the ass. Using it as an excuse not to use rails is just that: an excuse.