3 ms·

> But on the Ruby side, stuff gets deprecated/broken all the time, so we need much more manpower to maintain it. Maybe you should consider Perl? I'm only half

> But on the Ruby side, stuff gets deprecated/broken all the time, so we need much more manpower to maintain it. Maybe you should consider Perl? I'm only half joking. I have a few Perl projects running unchanged for 15 years and hopefully for the next 15 years as well.

tomc1985 5y ago
Considering how much Ruby borrows from Perl that is one of the better suggestions I've seen here
fxtentacle 5y ago
I don't have that much Perl experience, but I was positively impressed with Python CGI scripts. And with statically linked things like C/C++/Go. Haven't tried Rust in production yet. Plus I still use one service in production which was written in C++ in 2009. It's statically linked and as such the binary survived 3 major OS upgrades unmodified. Around 2015 I put it behind Nginx just to be sure with all the OpenSSL issues being discovered. It was designed to be multi-threaded to fully take advantage of a dual-core Athlon with 2GB RAM. Oh wow is that one blazing fast on today's hardware.
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 ago
  Software 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.

tomc1985 5y ago

Considering how much Ruby borrows from Perl that is one of the better suggestions I've seen here

fxtentacle 5y ago

I don't have that much Perl experience, but I was positively impressed with Python CGI scripts. And with statically linked things like C/C++/Go. Haven't tried Rust in production yet. Plus I still use one service in production which was written in C++ in 2009. It's statically linked and as such the binary survived 3 major OS upgrades unmodified. Around 2015 I put it behind Nginx just to be sure with all the OpenSSL issues being discovered. It was designed to be multi-threaded to fully take advantage of a dual-core Athlon with 2GB RAM. Oh wow is that one blazing fast on today's hardware.

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 ago
Software 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.