3 ms·
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 le
by brightball 4y ago
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 4y agoEvery 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 4y agoDuring 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 4y agoI 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 4y agoDid you go straight from 4 to 7 or 4, 5, 6, 7?
- Fire-Dragon-DoL 4y agoThere 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