[brightball]

I've worked with a lot of Rails code bases over the last 10 years and just haven't ever experienced this problem from a types perspective.

Certainly, if you let gems start to get out of date the dependency chains to get them updated can become a task but that's fairly true of any language. It's one of the selling points for moving parts of an app to isolated services too.

Everything is a tradeoff though. I don't know that you can get the Aspect Oriented Programming gains that you get with Ruby and Rails with a more strictly typed language.

[Fire-Dragon-DoL]

Every Rails upgrade is kinda proof of the problem, isn't it?

There is an entire market on Google of companies expert in upgrading Rails, that to me is a bad signal.

(notice, I have almost 15 years of experience with rails)

[brightball]

During the Ruby 1.8.7 to 1.9 transition there was a lot of complexity to things, but it hasn't really been a big problem since then has it?

[Fire-Dragon-DoL]

I dodged that, started getting serious with rails 3 and ruby 1.9+

No,there are still many undocumented breaking changes. I recently upgraded an old app from Rail 4 to 7 that used minimal non-rails stuff and was shocked by the corner cases.

Manu changes to activerecord api go completely undocumented, but they break the code nonetheless

[brightball]

Did you go straight from 4 to 7 or 4, 5, 6, 7?

[Fire-Dragon-DoL]

There is no upgrade guide from 4 to 7,so I did from 4.2 to 5,from 5 to 5.1, from 6 to 6.1 and then to 7.

I actually found a bug that broke my app at version 6 that was resolved in 6.1,so technically my tests were not passing in version 6 and I did an "unsafe upgrade" to version 6.1