Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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)


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?


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


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


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: