The joy of rediscovering Perl

40 points by henrytill

I like the sentiment here, and even as python is my default choice for so many things, for certain tasks, I jump straight to perl.

But this:

The past months NPM-shenanigans made me long for the days where I could, for the most part, install my dependencies through my distro package manager, and not pull the latest and greatest (and backdoored) version from a third party package registry.

doesn't align with my memories of using perl heavily. perl -MCPAN -e shell was a regular thing in my world, and I don't remember anything that made that safer than what people do with npm now.

henrytill

OTOH, using Debian/apt to manage to your Perl dependencies, as the author describes, tends to be more secure than pulling from CPAN directly.

But you're right, AFAIK there's nothing about the CPAN model that makes it more secure than npm, other than being far less used.
wink

With my old sysadmin hat on, at least on Debian (2000-2010ish) your ops tools probably didn't need anything fancy or released the last month, so installing 100% of perl modules via apt worked fine.

I've never been a Perl developer, so I can imagine this might not have been true if you were writing "applications" and not mostly monitoring & helper scripts
- scruss
  
  Using 100% apt-installed modules was fine, if you could live with some of them being older. But apt has (had?) a strict rule that one package installation couldn't modify another packages files. CPAN has no such qualms, so mixing apt and CPAN modules could end quite badly.
  
  And it did, back in 2008 or so. The Debian version of XML::SAX wasn't compatible with the same library on other distributions. Installing the CPAN XML::SAX over the Debian one caused all sorts of chaos which threatened to break apt completely. Luckily it could be backed out, but it wasn't fun
masklinn

Distros, at least of the Debian lineage, package a fair number of Perl libraries. But as usual with Debian you get whatever you get, which might be way outdated or even wonky patchworks.

You can do the same for Python, if you apt search python3- you’ll see a lot of stuff which is technically available without going through pip. Likewise Ruby, and even node.
- intelfx
  
  You can do the same for Python, if you apt search python3- you’ll see a lot of stuff which is technically available without going through pip.
  
  That's how I strive to use Python, too.
- vrthra
  
  Isn't doing this kind of discouraged? My understanding is that all the apt python3- libraries are for your system Python, which you are not supposed to touch.
  - sknebel
    
    Writing scripts targeting the system environment is fine, e.g. for ease of distribution. Installing additional external dependencies into is is discouraged/prevented.
  - masklinn
    
    The entire point of the python3- packages is to be installed into the global python. Working together is rather the point of packaged libraries. By doing that you're not doing anything more than if you'd installed some software which happened to depend on all of those libraries.
    
    Installing from pip (or equivalent for other language) into the system python is what's frowned upon.
- TeddyDD
  
  I actually wish there was something like nmp or uv for Perl. CPAN is full of interesting packages but installing things globally instead of per-project feels iffy in $CURRENT_YEAR.
  - mxey
    
    https://metacpan.org/pod/local::lib
    
    reezer
    
    And that's widely supported. Eg. cpanm supports it. Don't know if that's still widely used though, haven't done any Perl in a very long time, but this makes me want to pick it up again.
  - domm
    
    And of course you can use containers to run & deploy your Perl apps, which makes the question of installing deps globally or locally quite irrelevant.
    
    BTW, local::lib was first released in 2007, and perlbrew (a tool to install and manage different versions of Perl itself on your machine) exists since 2010. So Perl had these tools for ages.
  - adavis
    
    There's no uv equivalent I'm aware of.
    
    But there are some options.
    
    carton, is like bundler, and will install dependencies in the project directory.
    
    Personally I use plenv which is like ruby's rbenv. Install perl versions in your homedir, and install dependencies with cpanm with dependencies installed alongside the perl version.
    
    domm
    
    You can use perlbrew to manage different versions of Perl. Together with carton I guess it's quite similar to uv.
    
    adavis
    
    Yep, can combine plenv with carton to do the same thing.
    
    Just doesn't quite have the integration of uv to manage both (and other things like uv tool install)
    
    squarism
    
    I think the Perl Black Book was the first tech book I read cover to cover and I was enthralled. It was my first real language and I tried to (over)use it for everything. If you want that energy, I think Ruby is a better Perl - 2011 post, eesh. It's syntax and spirit is similar in a lot of ways and it was inspired partly by it, which is why it retains familiar globals like ARGV and others, regex syntax, regex capture groups $, heredocs, .chomp(), %w(word arrays)`.
    
    I don't think I can work without project isolation. I don't use system-installed languages. I have projects that need different versions of stuff. So, Ruby figured out project dependency isolation with Bundler a long time ago and others have been following suit (uv, poetry). "Perl is already installed, I'll just use that. It works." doesn't really capture the whole problem space. I think it's a "works on my machine" setup. I think it's the problem setup, like a prelude, for "invent package manager".
    
    But yes, revisit stuff. Check your nostalgia and memories. Check someone else's nostalgia and memories. It's doable with VMs and sandboxes. I have done this recently and it was interesting and grounding for me. :)
    
    If this is all coming from the security angle, there's not really a solution to security practices. There are habits, mitigations, tools, defense and posturing, vigilance but no security solving product. We could recreate the NPM hack/problem in CPAN. To me, there are differences in the culture, foundation/funding, organization, community, people and history. And certain tools and technical details I do think influence thought, so I guess it's techno-socio (sure, easy generalization statement) but you can't switch languages to avoid security but you could enter into a different culture which maybe you like more.
    
    my point and timing of "use ruby" is maybe not great considering the rubygems stuff ... oh well :)
    
    ltriant
    
    I rediscovered Perl again recently too.
    
    I spent 10 years developing systems in Perl, and we were always pinned to 5.8.9, so being able to use the newer features from recent versions for my own personal projects has been really refreshing.
    
    I also started designing a little programming language, and immediately thought of various Perl and Raku features that I wanted.
    
    srtcd424
    
    Youngster! 5.004 was the One True Version ;-)
    
    I still miss being able to "get away with" choosing perl. It still feels faster and lighter than python, golang, etc.
    
    laat
    
    Just this morning I checked the size of OCI images with python or perl added to alpine. The image sizes were 51 and 48 MB respectively.
    
    Edit: Just alpine is 9MB and with Lua it is 10MB.
    
    srtcd424
    
    Might depend what modules are bundled with it. I was thinking of RAM usage really, though I've not done proper benchmarks.
    
    alper
    
    Please no. Some things should be left behind.
    
    ars_dev_br
    
    I felt this article is a bit light on what makes the language a pleasure to work with. Is it just because the dependencies are in the distro packages? Are there language features that make it nicer to use than say Python or Ruby?