4 ms·

And other people love chasing new shiny things. I'm yet to see another language ecosystem that solves 99.99% of the problems one might have the way CPAN does.

And other people love chasing new shiny things. I'm yet to see another language ecosystem that solves 99.99% of the problems one might have the way CPAN does. Would I write an API in perl? Nope. Would I write something that massages the data that APIs spit out and processes it, drops into a queues, generates jobs, etc? Absolutely. Mostly because I will write a few hundred lines of code for existing CPAN modules to solve the problem that I have, letting me to move on to doing something else. I like boring tools that just work. In 99.99% of the times the tools/whatever you are writing is not inline, does not need to have amazing performance. It just need to work and be braindead simple. Perl excels at that. I still daily use code that I wrote over 25 years ago and modified it a couple of times since that point ( integrating git ). Edit: Can't reply below so I will reply here: Re: I would not write an API in perl. > I see you have not tried Mojolicious. I have seen it, tried it, got excited about it and immediately came to my senses because I asked myself "Why on earth would I build or advise people to build an API in perl? It is slow. It is bad for concurrency. It probably has a pile of corner cases that I'm or some other people are going to discover. If I need to ingest something via web I will throw a simple nodejs app. Millions played with it actively in a "web" sphere, and hit most of the corner cases. There are thousands articles on stackoverflow and we have dozens of skeleton servers that already have all the needed foundations, including federated databases that support live password changes, traffic sharding, online promotion and switches, dynamic reloads, do-at-most-once queues, do-at-least-once queues, etc etc. Why would I want to reinvent all of this when the job of the API is to get the stuff and if the question cannot be answered via a couple of lookups push the request to a worker?" Re: CPAN in 2019 > n 2019, I can only think you haven't looked around much recently. Maybe. I have not seen it to be the case two months ago.

jerf 7y ago
"I'm yet to see another language ecosystem that solves 99.99% of the problems one might have the way CPAN does." In 2010, that may have been true. In 2019, I can only think you haven't looked around much recently.
Grinnz 7y ago
> Would I write an API in perl? Nope. I see you have not tried Mojolicious.
- lilSebastian 7y ago
  Mojo makes all web based work almost effortless. Many thanks to you and the other contributors
donaldihunter 7y ago
> Would I write an API in perl? Nope Why not? There are CPAN frameworks that make it a breeze. The most efficent "modern" web development I have done has been with Perl. Mojolicious, Catalyst, Dancer – take your pick.
Grinnz 7y ago
I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl. Yes, Perl's threading support is terrible, and I do wish it was as effortless as in Raku. But you'd be surprised how often you actually only need an event loop and non-blocking implementations, and for the rest of the time there's Mojo::IOLoop->subprocess or IO::Async::Function to provide a thread-like model with efficient forking.
- notyourday 7y ago
  > I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl Because there have not been million people with different levels of skills poking and prodding Mojolicious into good, bad, ridiculous, disgusting, ugly and beautiful uses, posting on Stackoverflow, getting answers, getting smacked down, or getting those things marked as known bugs. I use code to achieve a business objective, not to create a beautiful code or use a wonderful framework. Just framework itself is not enough - it needs to have skeletons for services that would handle common edge cases -- database failures with automated switch to standby, internal request queues with retries, configurable. Clean interface to external configurations that should be changeable in-flight without a restart; patterns for interfacing with other systems, etc. > Yes, Perl's threading support is terrible, Some of the basic crypto modules and modules that use those basic crypto modules are not thread safe. In 2019. Modules that were written a decade ago. I'm not interested in figuring out those bugs in production. I wrote a pretty complex API using Dancer. I'm not going there again.
  - Grinnz 7y ago
    Okay, I see. You should use what most easily provides the features you want, to be sure, and it certainly has not been battle tested the way, say, Catalyst has. But I think you are still selling it short. Mojolicious is foremost about consistency and practicality, beauty (if you would consider it that) is simply a side effect; and it is probably in more use than you think.

jerf 7y ago

"I'm yet to see another language ecosystem that solves 99.99% of the problems one might have the way CPAN does." In 2010, that may have been true. In 2019, I can only think you haven't looked around much recently.

Grinnz 7y ago

> Would I write an API in perl? Nope. I see you have not tried Mojolicious.

lilSebastian 7y ago
Mojo makes all web based work almost effortless. Many thanks to you and the other contributors

donaldihunter 7y ago

> Would I write an API in perl? Nope Why not? There are CPAN frameworks that make it a breeze. The most efficent "modern" web development I have done has been with Perl. Mojolicious, Catalyst, Dancer – take your pick.

Grinnz 7y ago

I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl. Yes, Perl's threading support is terrible, and I do wish it was as effortless as in Raku. But you'd be surprised how often you actually only need an event loop and non-blocking implementations, and for the rest of the time there's Mojo::IOLoop->subprocess or IO::Async::Function to provide a thread-like model with efficient forking.

notyourday 7y ago
> I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl Because there have not been million people with different levels of skills poking and prodding Mojolicious into good, bad, ridiculous, disgusting, ugly and beautiful uses, posting on Stackoverflow, getting answers, getting smacked down, or getting those things marked as known bugs. I use code to achieve a business objective, not to create a beautiful code or use a wonderful framework. Just framework itself is not enough - it needs to have skeletons for services that would handle common edge cases -- database failures with automated switch to standby, internal request queues with retries, configurable. Clean interface to external configurations that should be changeable in-flight without a restart; patterns for interfacing with other systems, etc. > Yes, Perl's threading support is terrible, Some of the basic crypto modules and modules that use those basic crypto modules are not thread safe. In 2019. Modules that were written a decade ago. I'm not interested in figuring out those bugs in production. I wrote a pretty complex API using Dancer. I'm not going there again.
- Grinnz 7y ago
  Okay, I see. You should use what most easily provides the features you want, to be sure, and it certainly has not been battle tested the way, say, Catalyst has. But I think you are still selling it short. Mojolicious is foremost about consistency and practicality, beauty (if you would consider it that) is simply a side effect; and it is probably in more use than you think.