11 ms·

I'm curious to know if anyone out there building new systems in Perl or is it all just maintenance mode for Perl based systems?

7r7292DuMfMz1Rh 4y ago
Unfortunately, yes, people are still building new systems in Perl. In my experience, it's been because existing infrastructure that new systems need is already written in Perl. I'll note that if you use a strict subset of Perl, and write it well, with lots of unit tests, it's bearable to use. But it falls massively short when it comes to anything concurrent or async. And if you stray into the "clever" subset of Perl, frankly it becomes hell. The ecosystem is also pretty much dead, it's not unusual to find bugs in packages where the issue tracker hasn't been responded to in 10 years, and the issue for the bug you're interested in has been languishing for literally years.
- davorg 4y ago
  > The ecosystem is also pretty much dead, it's not unusual to find bugs in packages where the issue tracker hasn't been responded to in 10 years, and the issue for the bug you're interested in has been languishing for literally years. Yes. Very much this. Anecdotally, I'd estimate that, outside of the big, well-known modules, about 25% of the CPAN modules I try to use have bugs that render them unusable and unresponsive maintainers. Here's a description of an example I found last year - https://dev.to/davorg/failing-to-get-product-information-from-amazon-with-perl-5a3g https://dev.to/davorg/failing-to-get-product-information-fro... (my project to write a replacement module has stalled).
- biorach 4y ago
  > And if you stray into the "clever" subset of Perl, frankly it becomes hell Yeah, this is the thing... it's very very easy to go down a one-way street to an endless hell of incomprehensible line-noise code and "clever" tricks that are incomprehensible and unmaintainable. On the plus side, having dealt with the hell of "clever" perl early in my career (and, ahem, maybe having been guilty of writing some), it has beaten into me the absolute necessity of writing the simplest, clearest, not-clever code possible. In some other language.
- petre 4y ago
  > But it falls massively short when it comes to anything concurrent or async Nonsense, there's AnyEvent, EV, IO::Async, Mojo::IOLoop. If you need parallelism, yes, you'd better use Go or something else. And the 10 years old bugs are to a large extent an exageration, because those modules are probably abandoned and you shouldn't use them anyway.
  - 7r7292DuMfMz1Rh 4y ago
    > Nonsense, there's AnyEvent, EV, IO::Async, Mojo::IOLoop My experience with all of these has been that they've been frustrating to work with, and general support for them in the broader ecosystem is lacking and mutually incompatible. > those modules are probably abandoned and you shouldn't use them anyway. Yes, that's the point, the ecosystem is now lacking because of the number of abandoned modules (even for quite common stuff).
    - petre 4y ago
      Mojo::IOLoop is quite lean and straightforward to work with, but it's quite minimal. If I'd pick something, I'd probably pick this one as the decision to use Mojolicious was very rewarding. AnyEvent is harder because it uses closures everywhere but it works really nicely otherwise. It's not endorsed by some in the Perl community because the author insists that it doesn't need a license and chooses to develop it and track bugs on his own infrastructure. EV is developed by the same author and it requires a compiler, it can be plugged into AnyEvent. They're both very good quality. IO::Async is a different event loop brought to you by the people that do not endorse AnyEvent but are involved with Perl 5 development. I haven't used it, but it has a large number of active bugs on RT, plus past criticism from the author of AnyEvent. There's also POE which we use but it's possibly on life support and you probably wouldn't want to use it unless you want to live in callback hell, so I fully understand your frustration if you've actually tried it. We use POE in a critical part of our infrastructure and has worked fine, but that part is quite frustrating to maintain. Futher criticism of this event framework could be found here: https://metacpan.org/pod/AnyEvent::Impl::POE https://metacpan.org/pod/AnyEvent::Impl::POE As a sidenote, I'm curreny working with Ruby's Async:IO which is a breath of fresh air compared to other event loops that I've worked with in the past.
- doomvox 4y ago
  > it falls massively short when it comes to anything concurrent or async Perl has some decent CPAN modules for handling multi-process applications-- it is true that it's very weak for threaded applications. (Raku on the other hand has some extremly convenient CAP features in general.)
asicsp 4y ago
See this discussion from 2 years back: https://news.ycombinator.com/item?id=25021660 https://news.ycombinator.com/item?id=25021660
davorg 4y ago
Speaking as a London-based freelancer specialising in Perl, I can tell you that the number of companies developing new systems in Perl is tiny (like, maybe, half a dozen). Until four or five years ago, there was still plenty of maintenance work to be had, but even that has pretty much dried up now.
- gjvc 4y ago
  what are you going to do then?
  - davorg 4y ago
    I'm semi-retired. I have a part-time contract maintaining a system I worked on a few years ago and I pick up other bits of freelance work from time to time. And I've been prototyping a few project ideas (in Perl) to see if any of them could be a sustainable source of passive income. Of course, if any of them grow to the extent that they need a development team, I'll need to rewrite them in a more sustainable language.
  - 323 4y ago
    Maybe he'll wait for the Y2038 crisis :p
    - davorg 4y ago
      Hey, it worked for the COBOL crowd 25 years ago :-)
- cutler 4y ago
  I think Ruby is heading in the same direction.
  - reducesuffering 4y ago
    Yes, the trend of usage metrics don't look promising. It's basically only used for Rails and the heyday was 2010-2016. People are much more likely to reach for Django/Python or Javascript backends, especially with the ubiquity of React. Ruby jobs are going to generally be maintenance of older projects.
forgotmypw17 4y ago
I chose to build in Perl because of its ubiquity and committment to backwards compatibility. I was extremely frustrated with existing projects having dependency issues and frequent breakage and wanted to avoid that at all costs. Perl's flexibility has allowed me to develop my own coding style, which is basically Java-like, and I rarely have trouble figuring out what something does, even months later. I think Perl is vastly underrated as a language, and its suffers from repeat-speak of people who have only seen poorly written Perl or have never seen a well-managed Perl project. One of my favorite things about Perl is that there are 20 years of code samples on the Web for it and they ALL WORK because Perl has not introduced breaking changes since 5.000.
- xupybd 4y ago
  I found Perl suffered from dependency issues as well. Not the language but the modules you tend to want to use. Especially when they're underpinned by c libraries. I'd preference operating system libraries then fall back to Cpan. Over time it got harder to maintain older applications as the libraries dropped out of repositories. Have you found anything similar?
  - forgotmypw17 4y ago
    You're right, and this is why I don't use third-party modules. If I need something I can't write myself, I use the shell version instead of a module.
    - scoopertrooper 4y ago
      Seems like you're jumping through a like of hoops to write thing in a Java-like fashion when you could be using Java, which has a much healthier ecosystem.
      - forgotmypw17 4y ago
        Java has many other shortcomings which keep me from using it.
danrocks 4y ago
Amazon's language for storefront UI templates is Perl [1]. When I joined, I couldn't help but laugh that poor developers are dragged through the hell of 5 leetcode interviews to end up working on a UI framework that is 25 years old. [1] http://www.masonhq.com/sites http://www.masonhq.com/sites Edit: I left in 2013 so I don't know if it's still the case.
- alfiedotwtf 4y ago
  To be fair, HTML::Mason was probably the most powerful templating toolkit at the time (Text::Template was there too, but from memory Mason was almost everyone's goto).
samwillis 4y ago
Not new, but I'm currently working on a freelance project modernising the front end / UI of a bioinformatics platform that's written in Perl. Also I wouldn't say it's in maintenance mode, there are new features being developed for it all the time.
jwr 4y ago
Perl is very well suited for certain tasks (not large software systems, but programs that process data). It is also one of very few languages/ecosystems where you can expect your code to work after >10 years. This is why I sometimes use it, for example my fs consistency checker (https://github.com/jwr/ccheck https://github.com/jwr/ccheck) was written in Perl specifically because it's a long-term tool and I would like to be able to run it on any system in 15 years. Compare this long-term approach with the fires in Python or (heaven forbid) Node ecosystems, where things break all the time.
- hollander 4y ago
  > because it's a long-term tool and I would like to be able to run it on any system in 15 years What about Docker and Virtualenv? Both make it possible to keep running code until the end of times.
  - xmcqdpt2 4y ago
    I've also used Perl for small utility programs (basically as a "enhanced" shell script). The problem with Docker or virtualenvs is that they greatly increase the installation complexity of your script. For example, two years ago I wrote a small (50 LOC) Perl script to convert between two text format. On Unix you could install it by just putting the one file in /usr/bin. It would run in less than 1 ms, which was critical because it was repeatedly invoked by another (legacy) program. It was mostly a bunch of regex so it was natural to write it in Perl (or awk maybe but I don't know awk). The python equivalent would have been at least 30x slower, significantly longer, less portable etc. Using docker just for this script would have been overkill. The only real alternative IMO would have been to make a statically compiled Go or Rust binary.
  - jwr 4y ago
    I do use Docker for freezing dumpster fires like CSS toolkits that need to be built using node. And that works well to a certain extent, but there is still the complexity of Docker, having to set it up when you want to use the tool, having to deal with changes happening in it over the years, setting up filesystem sharing, etc. Whereas with Perl it's easy: any UNIX system (and I do mean UNIX in a wide sense, as I've run perl on systems like HP-UX, Solaris, Unicos, IRIX and others) will normally have perl5 installed and you'll be able to just run your software. If it doesn't have perl5, installing it is usually very easy and you don't have to deal with horrors like the python2->python3 transition.
petre 4y ago
Maintainance can mean: reuse most of the business logic and port the software to another MVC framework, so it's easier to maintain and add new features, as opposed to keeping it running on life support.
ainar-g 4y ago
Perl seems to still be fairly popular with the OpenBSD folk, since a Perl installation comes with the base system. It seems to be pretty much the scripting language of choice when simple Shell scripts don't do the job or are too slow.
- johnisgood 4y ago
  Yup, their package manager and related stuff is written in Perl.
toast0 4y ago
I've built a few (small) things in Perl recently: a) iCalendar and timezone pre-processing for an Arduino alarm clock; Arduino libraries aren't up to the task (and neither am I! recurring events with recurring exceptions is kind of complex), but cpan iCal libraries and timezone libraries seem to work. b) personally monitoring script, checks a bunch of stuff and sends email (well, cron sends the email, really) if problems persist for long enough c) something to fetch my DSL sync speed and status (uses Net::Telnet), which feeds into the monitor script, but also used to adjust bandwidth limits for fq_codel to reduce bufferbloat.
nocman 4y ago
Yes, and not just maintenance, new systems.
mdaniel 4y ago
I don't know if they adopted some existing codebase, but DuckDuckGo is the most famous one I know of: https://github.com/orgs/duckduckgo/repositories?q=&type=all&language=perl https://github.com/orgs/duckduckgo/repositories?q=&type=all&...
ei8ths 4y ago
yes, I am. Web apps and scripting.

7r7292DuMfMz1Rh 4y ago

Unfortunately, yes, people are still building new systems in Perl. In my experience, it's been because existing infrastructure that new systems need is already written in Perl. I'll note that if you use a strict subset of Perl, and write it well, with lots of unit tests, it's bearable to use. But it falls massively short when it comes to anything concurrent or async. And if you stray into the "clever" subset of Perl, frankly it becomes hell. The ecosystem is also pretty much dead, it's not unusual to find bugs in packages where the issue tracker hasn't been responded to in 10 years, and the issue for the bug you're interested in has been languishing for literally years.

davorg 4y ago
> The ecosystem is also pretty much dead, it's not unusual to find bugs in packages where the issue tracker hasn't been responded to in 10 years, and the issue for the bug you're interested in has been languishing for literally years. Yes. Very much this. Anecdotally, I'd estimate that, outside of the big, well-known modules, about 25% of the CPAN modules I try to use have bugs that render them unusable and unresponsive maintainers. Here's a description of an example I found last year - https://dev.to/davorg/failing-to-get-product-information-from-amazon-with-perl-5a3g https://dev.to/davorg/failing-to-get-product-information-fro... (my project to write a replacement module has stalled).
biorach 4y ago
> And if you stray into the "clever" subset of Perl, frankly it becomes hell Yeah, this is the thing... it's very very easy to go down a one-way street to an endless hell of incomprehensible line-noise code and "clever" tricks that are incomprehensible and unmaintainable. On the plus side, having dealt with the hell of "clever" perl early in my career (and, ahem, maybe having been guilty of writing some), it has beaten into me the absolute necessity of writing the simplest, clearest, not-clever code possible. In some other language.
petre 4y ago
> But it falls massively short when it comes to anything concurrent or async Nonsense, there's AnyEvent, EV, IO::Async, Mojo::IOLoop. If you need parallelism, yes, you'd better use Go or something else. And the 10 years old bugs are to a large extent an exageration, because those modules are probably abandoned and you shouldn't use them anyway.
- 7r7292DuMfMz1Rh 4y ago
  > Nonsense, there's AnyEvent, EV, IO::Async, Mojo::IOLoop My experience with all of these has been that they've been frustrating to work with, and general support for them in the broader ecosystem is lacking and mutually incompatible. > those modules are probably abandoned and you shouldn't use them anyway. Yes, that's the point, the ecosystem is now lacking because of the number of abandoned modules (even for quite common stuff).
  - petre 4y ago
    Mojo::IOLoop is quite lean and straightforward to work with, but it's quite minimal. If I'd pick something, I'd probably pick this one as the decision to use Mojolicious was very rewarding. AnyEvent is harder because it uses closures everywhere but it works really nicely otherwise. It's not endorsed by some in the Perl community because the author insists that it doesn't need a license and chooses to develop it and track bugs on his own infrastructure. EV is developed by the same author and it requires a compiler, it can be plugged into AnyEvent. They're both very good quality. IO::Async is a different event loop brought to you by the people that do not endorse AnyEvent but are involved with Perl 5 development. I haven't used it, but it has a large number of active bugs on RT, plus past criticism from the author of AnyEvent. There's also POE which we use but it's possibly on life support and you probably wouldn't want to use it unless you want to live in callback hell, so I fully understand your frustration if you've actually tried it. We use POE in a critical part of our infrastructure and has worked fine, but that part is quite frustrating to maintain. Futher criticism of this event framework could be found here: https://metacpan.org/pod/AnyEvent::Impl::POE https://metacpan.org/pod/AnyEvent::Impl::POE As a sidenote, I'm curreny working with Ruby's Async:IO which is a breath of fresh air compared to other event loops that I've worked with in the past.
doomvox 4y ago
> it falls massively short when it comes to anything concurrent or async Perl has some decent CPAN modules for handling multi-process applications-- it is true that it's very weak for threaded applications. (Raku on the other hand has some extremly convenient CAP features in general.)

asicsp 4y ago

See this discussion from 2 years back: https://news.ycombinator.com/item?id=25021660 https://news.ycombinator.com/item?id=25021660

davorg 4y ago

Speaking as a London-based freelancer specialising in Perl, I can tell you that the number of companies developing new systems in Perl is tiny (like, maybe, half a dozen). Until four or five years ago, there was still plenty of maintenance work to be had, but even that has pretty much dried up now.

gjvc 4y ago
what are you going to do then?
- davorg 4y ago
  I'm semi-retired. I have a part-time contract maintaining a system I worked on a few years ago and I pick up other bits of freelance work from time to time. And I've been prototyping a few project ideas (in Perl) to see if any of them could be a sustainable source of passive income. Of course, if any of them grow to the extent that they need a development team, I'll need to rewrite them in a more sustainable language.
- 323 4y ago
  Maybe he'll wait for the Y2038 crisis :p
  - davorg 4y ago
    Hey, it worked for the COBOL crowd 25 years ago :-)
cutler 4y ago
I think Ruby is heading in the same direction.
- reducesuffering 4y ago
  Yes, the trend of usage metrics don't look promising. It's basically only used for Rails and the heyday was 2010-2016. People are much more likely to reach for Django/Python or Javascript backends, especially with the ubiquity of React. Ruby jobs are going to generally be maintenance of older projects.

forgotmypw17 4y ago

I chose to build in Perl because of its ubiquity and committment to backwards compatibility. I was extremely frustrated with existing projects having dependency issues and frequent breakage and wanted to avoid that at all costs. Perl's flexibility has allowed me to develop my own coding style, which is basically Java-like, and I rarely have trouble figuring out what something does, even months later. I think Perl is vastly underrated as a language, and its suffers from repeat-speak of people who have only seen poorly written Perl or have never seen a well-managed Perl project. One of my favorite things about Perl is that there are 20 years of code samples on the Web for it and they ALL WORK because Perl has not introduced breaking changes since 5.000.

xupybd 4y ago
I found Perl suffered from dependency issues as well. Not the language but the modules you tend to want to use. Especially when they're underpinned by c libraries. I'd preference operating system libraries then fall back to Cpan. Over time it got harder to maintain older applications as the libraries dropped out of repositories. Have you found anything similar?
- forgotmypw17 4y ago
  You're right, and this is why I don't use third-party modules. If I need something I can't write myself, I use the shell version instead of a module.
  - scoopertrooper 4y ago
    Seems like you're jumping through a like of hoops to write thing in a Java-like fashion when you could be using Java, which has a much healthier ecosystem.
    - forgotmypw17 4y ago
      Java has many other shortcomings which keep me from using it.

danrocks 4y ago

Amazon's language for storefront UI templates is Perl [1]. When I joined, I couldn't help but laugh that poor developers are dragged through the hell of 5 leetcode interviews to end up working on a UI framework that is 25 years old. [1] http://www.masonhq.com/sites http://www.masonhq.com/sites Edit: I left in 2013 so I don't know if it's still the case.

alfiedotwtf 4y ago
To be fair, HTML::Mason was probably the most powerful templating toolkit at the time (Text::Template was there too, but from memory Mason was almost everyone's goto).

samwillis 4y ago

Not new, but I'm currently working on a freelance project modernising the front end / UI of a bioinformatics platform that's written in Perl. Also I wouldn't say it's in maintenance mode, there are new features being developed for it all the time.

jwr 4y ago

Perl is very well suited for certain tasks (not large software systems, but programs that process data). It is also one of very few languages/ecosystems where you can expect your code to work after >10 years. This is why I sometimes use it, for example my fs consistency checker (https://github.com/jwr/ccheck https://github.com/jwr/ccheck) was written in Perl specifically because it's a long-term tool and I would like to be able to run it on any system in 15 years. Compare this long-term approach with the fires in Python or (heaven forbid) Node ecosystems, where things break all the time.

hollander 4y ago
> because it's a long-term tool and I would like to be able to run it on any system in 15 years What about Docker and Virtualenv? Both make it possible to keep running code until the end of times.
- xmcqdpt2 4y ago
  I've also used Perl for small utility programs (basically as a "enhanced" shell script). The problem with Docker or virtualenvs is that they greatly increase the installation complexity of your script. For example, two years ago I wrote a small (50 LOC) Perl script to convert between two text format. On Unix you could install it by just putting the one file in /usr/bin. It would run in less than 1 ms, which was critical because it was repeatedly invoked by another (legacy) program. It was mostly a bunch of regex so it was natural to write it in Perl (or awk maybe but I don't know awk). The python equivalent would have been at least 30x slower, significantly longer, less portable etc. Using docker just for this script would have been overkill. The only real alternative IMO would have been to make a statically compiled Go or Rust binary.
- jwr 4y ago
  I do use Docker for freezing dumpster fires like CSS toolkits that need to be built using node. And that works well to a certain extent, but there is still the complexity of Docker, having to set it up when you want to use the tool, having to deal with changes happening in it over the years, setting up filesystem sharing, etc. Whereas with Perl it's easy: any UNIX system (and I do mean UNIX in a wide sense, as I've run perl on systems like HP-UX, Solaris, Unicos, IRIX and others) will normally have perl5 installed and you'll be able to just run your software. If it doesn't have perl5, installing it is usually very easy and you don't have to deal with horrors like the python2->python3 transition.

petre 4y ago

Maintainance can mean: reuse most of the business logic and port the software to another MVC framework, so it's easier to maintain and add new features, as opposed to keeping it running on life support.

ainar-g 4y ago

Perl seems to still be fairly popular with the OpenBSD folk, since a Perl installation comes with the base system. It seems to be pretty much the scripting language of choice when simple Shell scripts don't do the job or are too slow.

johnisgood 4y ago
Yup, their package manager and related stuff is written in Perl.

toast0 4y ago

I've built a few (small) things in Perl recently: a) iCalendar and timezone pre-processing for an Arduino alarm clock; Arduino libraries aren't up to the task (and neither am I! recurring events with recurring exceptions is kind of complex), but cpan iCal libraries and timezone libraries seem to work. b) personally monitoring script, checks a bunch of stuff and sends email (well, cron sends the email, really) if problems persist for long enough c) something to fetch my DSL sync speed and status (uses Net::Telnet), which feeds into the monitor script, but also used to adjust bandwidth limits for fq_codel to reduce bufferbloat.

nocman 4y ago

Yes, and not just maintenance, new systems.

mdaniel 4y ago

I don't know if they adopted some existing codebase, but DuckDuckGo is the most famous one I know of: https://github.com/orgs/duckduckgo/repositories?q=&type=all&language=perl https://github.com/orgs/duckduckgo/repositories?q=&type=all&...

ei8ths 4y ago

yes, I am. Web apps and scripting.