Hacker News Reader

Comment by 7r7292DuMfMz1Rh | Hacker News Reader

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.

View on HN

> 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-fro... (my project to write a replacement module has stalled).

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

> 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.)

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

> 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).

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

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.

Reply on news.ycombinator.com