2 ms·
It's not Ruby itself that has features being deprecated/broken all the time, it's the libraries they're using that are changing. If you built an app targeting
by tinco 5y ago
It's not Ruby itself that has features being deprecated/broken all the time, it's the libraries they're using that are changing.
If you built an app targeting Ruby 1.8.7 (~15 yrs old now?) with maybe rack and sinatra as your only dependencies using only the bare feature set that was available then, it would easily run on Ruby 3 with no code modifications. It would be a lot nicer than Perl too I bet.
If you rely on industry standard software libraries however, you have to keep in mind that keeping up with the industry standard is in the bargain.
- brimble 5y agoSoftware culture plays a role. If there's one big dog successful project around that everyone's using for a particular purpose and that crowds out and de facto kills other libraries that might do the same thing, but that project's leadership just loves breaking backward compatibility every two years (or more) and not providing security updates for older versions... well, you're stuck with frequent, painful upgrades that require code changes. If that's the norm for lots of projects in an ecosystem, it gets hard to do anything in that language without either avoiding many of its most useful libraries or having relatively high-cost long-term maintenance and/or projects that basically just die and have to be replaced with something new if they fall out of view of your developers for more than a few months at a time. OTOH, if the culture of a language is that mature, popular libraries tend not to receive breaking changes, even if the principal maintainer reads a blog post and falls in love with New Paradigm X, maintenance can be much cheaper/easier, while still using plenty of 3rd party libraries.