3 ms·
That's certainly one rosy way to describe it. Another more realistic explanation one is that it's just an awful language to work in and people aren't writing ne
by lordofgibbons 4y ago
That's certainly one rosy way to describe it. Another more realistic explanation one is that it's just an awful language to work in and people aren't writing new software in it.
I'm speaking as someone who had the misfortune of maintaining one of those 15 year old legacy Perl systems.
After finally rewriting the Perl based systems in Go, our outages went to nearly zero, and we could handle multiple times more traffic.
Engineer on-boarding was also easier because they could understand what was going on by just being able to read the code. A novel concept, I know.. /s But that was impossible to do with the Perl based services.
- ajsnigrutin 4y agoOf course "new guys" will learn the "language of the week", and "old bearded sysadmins" will continue using perl, but still.. i have stuff literally written a deacade+ ago, still working without issues, and i have stuff written in ruby, rewritten to python (2.6?), fixed for 2.7, and rewritten for python3, that I abondoned ~python 3.3, and rewritten in perl, just to be able to forget about it.
- jamespwilliams 4y ago> i have stuff literally written a deacade+ ago, still working without issues Maybe this works if you run your Perl in the exact same environment the whole time, or if you're writing stuff on a very small scale and don't need to use many CPAN modules. But for large applications, you'll be using CPAN modules heavily. And you'll need to run your Perl in new environments - if for no other reason, because you'll need to move to new operating system versions to pick up security updates. That's where the problems start. If you're using a reasonable number of CPAN modules, this inevitably breaks some of them. And because the Perl ecosystem is essentially dead, those third-party modules are usually abandoned.