13 ms·

They last line of the article summarizes it well: > Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release wi

They last line of the article summarizes it well: > Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year. Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.

freyfogle 6y ago
yes, definitely. If you are manipulating text, Perl is great.
politelemon 6y ago
Yes... We have some high revenue, important contract type systems written a long time ago and maintained by the same subject matter experts who simply move the codebases (old and new) to newer systems and stacks. As you can tell, the SMEs have no interest in learning other things and so any new initiatives that require them to implement it is subject to their preferences.
- hinkley 6y ago
  Many places don’t support antifragility. Having an old system that nobody wants to rewrite may not be a reflection on the engineers. You’re an expert, and a rewrite is going to expose you to a lot of scrutiny. You are going to break things, when maybe you haven’t broken things in a long time and people like it that way. So when some day arrives where a new fad is hot and it’s hard to impossible to find Perl programmers, the will create a new team to rewrite it badly because now they have no other choice. And of course the new folks are going to screw up, but that’s just expected.
  - gmmeyer 6y ago
    There's no need to rewrite a system that works and that you're not gonna change. While programming languages go out of fashion there will always be people who are capable of writing them. The median age of a cobol programmer has not changed in 20 years because more people keep learning the language. Demand in this case, will likely create its own supply.
    - hinkley 6y ago
      I tend to replace my car when it starts to show signs of future problems, not when I'm up to my eyeballs in repairs. We shouldn't really be treating software differently. The liability for a mission critical system that works but cannot be repaired climbs over time. Just because it works doesn't mean it isn't broken.
      - derriz 6y ago
        That analogy doesn't really work - software doesn't get worn out from interaction with users. If software is working and in use, then it's age doesn't matter. Evolution/flux is not the natural state of all software. I've seen plenty of business/enterprise software which has continued to provide business value for decades without structural or architectural changes.
        hinkley 6y ago
        Lots of security patches and infrastructure are held hostage by breaking changes to APIs. Eventually you have to upgrade, and the longer you have put it off the more painful it will be. And as we've seen with old video games, there are lots of timing problems that you simply never encounter on the original hardware but are impossible to ignore on recent vintage hardware.
    - ChiranSoogoor 6y ago
      Wisdom is in not in spending years and millions rewriting billions of lines of cobol code into a new language and then rewriting that other language into another newer language and so on … what's the problem in maintaining what's already working?!!
  - CountSessine 6y ago
    the will create a new team to rewrite it badly because now they have no other choice Given Perl’s legendary code-opacity and maintenance challenges, this kind of seems inevitable. After all, if you could at least read and decipher the old code, maybe you could reproduce it!
  - yellowapple 6y ago
    > and it’s hard to impossible to find Perl programmers Which I'm finding harder to understand as I learn more languages. Yeah, every language has its differences and idiosyncrasies, but as long as you have access to docs (if not third-party resources like expert blogs or Stack Overflow) it's pretty straightforward to figure those out and be reasonably productive relatively soon. That is: a senior programmer should have enough background knowledge to be able to be productive on any language ("polyglot" shouldn't be a big deal), and a junior programmer won't typically have enough experience in any particular language to be definitively a "$LANGUAGE programmer". In either case, whether or not a programmer already knows the language before being hired is kind of a moot point. My current dayjob was the first time I had written any non-trivial amounts of Python, Javascript, or C# in a professional capacity in my whole career. Being productive on them wasn't terribly hard - it's just different syntax around a lot of the same concepts (and sure, there were also some new concepts - took a good while for me to wrap my head around async/await, for example, coming from a background of message passing between threads or processes or actors - but those can be learned). Usually the choice of programming language is far less significant as a barrier to one's understanding of a codebase than, say, the actual problem domain. Writing software for, say, a warehouse tends to necessitate knowing an awful lot about how warehouses work; whether or not you happen to know a given programming language is entirely secondary to whether or not you know the difference between a picker and a packer, or between a replenishment and a cycle count. Similar deal in medicine, or education, or manufacturing, or sales, or finance, or what have you.
    - hinkley 6y ago
      A former boss was fond of saying "Software is done when nobody is willing to work on it anymore." New people make idiomatic mistakes, and if the language isn't cool they expect more money. Recruiting people is harder, so you tend to get stuck with the people you have, and managers tend to bristle at that. Eventually a new language full of people who look like cogs is going to win out. I hate that this is true, but it is. I maintained a Python test harness for a while. No prior experience with Python. I mostly stayed out of trouble, in part because I set low expectations, tried nothing fancy. But it wasn't what I wanted to be doing, and not what I wanted the team to be doing. When I left they finally canned the entire thing.
  - codr7 6y ago
    There are plenty of silly reasons to rewrite a piece of code, but language preference has to be one of the worst. Now that I think about it, that's actually a decent hiring test: Tell the candidate part of their job will be maintaining a small Perl codebase. If they can't deal with that without throwing a fit, I have no interest in working with them. It's a sharp tool, if you're not careful someone might get hurt. But professionals deal with sharp tools all the time, especially when it's the best tool for the job.
smaili 6y ago
IIRC Craigslist was written in Perl but that's the only high traffic site that comes to mind.
- 1-more 6y ago
  I know some fantasy sports site was, maybe CBS? I had a UX designer colleague who had worked on that.
  - hnlmorg 6y ago
    A surprisingly large number of fantasy sports sites are. Perl is everywhere, it's just not widely publicised because of the stigma attached to the language.
- ori_b 6y ago
  duckduckgo, as far as I recall.
- petethered 6y ago
  Duck Duck Go and Booking.com were/are Perl backends.
- chubot 6y ago
  I think they still write everything in Perl, and they employ Larry Wall (or they did several years ago, last I heard)
- Twirrim 6y ago
  The Amazon retail site is written in perl (at least the presentation layer still is, you can find mason references still in the HTML source if you go looking, don't know how much else behind it is in perl). https://metacpan.org/pod/Mason https://metacpan.org/pod/Mason (if you're not familiar with Mason)
  - autarch 6y ago
    Actually, that's Mason 2. Amazon use(s|d) the OG Mason - https://metacpan.org/release/HTML-Mason https://metacpan.org/release/HTML-Mason
jpxw 6y ago
Yep, I know of one company still actively using Perl for a large part of its infrastructure. It has its use cases.
- noja 6y ago
  Booking.com?
  - jpxw 6y ago
    Nope :)
    - deleted 6y ago
      [deleted]
- paultopia 6y ago
  are the use cases all really really fancy regexes?
  - deleted 6y ago
    [deleted]
- Diederich 6y ago
  One that is definitely still using Perl in a very big way is https://www.ariba.com/ https://www.ariba.com/ Ariba isn't a household name, but it has deep and widespread connections to thousands of the largest companies in the world.
- noema 6y ago
  Are they named after a very large tropical rainforest?
nchelluri 6y ago
> Are there actually people that are still deploying new things in Perl? See https://news.ycombinator.com/item?id=23593835 https://news.ycombinator.com/item?id=23593835
1996 6y ago
I do. Efficient, cheap and stable. Ported to about everywhere.
- smabie 6y ago
  What do you mean by cheap? Also, perl is incredibly inefficient: it's even slower than Python. Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?
  - kbenson 6y ago
    > it's even slower than Python. It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes. > Are you saying the language doesn't change much or that it doesn't crash? Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.
  - 1996 6y ago
    - Efficient: from prototype to deployment, it's a matter of days. The choice of styles let people use paradigms they are familiar with, meaning they do things quickly. - Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage. - Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.
    - continuational 6y ago
      The reason that code written 20 years ago still runs fine is that they rolled back 20 years of changes!
      - 6y ago
nicoburns 6y ago
I believe MoveGB is running a perl backend.
triangleman 6y ago
I'm working through the Llama book, seems like a fun alternative to Python.
benbristow 6y ago
I used to work for a company that used Perl as their primary language. The codebase was millions of lines long, modules (pm files) with like 1000 methods and 10,000 lines, a total mess and it had 0 unit tests too. Almost beyond salvageable. Left a bit of a sour taste. They're trying to migrate to AWS but AWS don't even natively support Perl in their libraries. There's a few third party libraries in CPAN but nothing as comprehensive as what's available with official libraries for other languages. Nothing against the language but I don't know why you wouldn't use literally anything else nowadays. Python or PHP, JavaScript or even Ruby if you're looking for a dynamically typed language. AWS don't even support Perl.
- ugexe 6y ago
  Your opinion on Perl is based on one code base you worked at on one job?
  - w0m 6y ago
    Honestly that's more than most I think. I've written tens of thousands of lines of perl professionally and I generally share the same opinion.
    - nchelluri 6y ago
      I've been writing (Modern) Perl for about 3.5 years and I disagree that Perl necessarily tends to unreadable code. I really don't think that's true at all. To quote myself from a recent discussion: I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ all the time], code linters, and so on) I think how you use a language plays a huge part in code maintainability. For instance, I've heard PHP get shit on pretty badly all around the web, but I've worked at PHP shops that had nice, clean codebases, and my current Perl codebase is, in many ways, nicely structured. That's not to say there aren't some hairy codepaths that could use refactoring, but I really think that kind of thing, again, can happen in almost any language.
Lammy 6y ago
> Are there actually people that are still deploying new things in Perl? Anecdote: I found this Perl image-hosting package a couple years ago as a self-hosted alternative to sites like Imgur, and I think it's great: https://framagit.org/fiat-tux/hat-softwares/lutim/tree/master https://framagit.org/fiat-tux/hat-softwares/lutim/tree/maste...
jhowell 6y ago
I think the US Courts still use Perl for Pacer (https://www.pacer.gov/psco/cgi-bin/links.pl https://www.pacer.gov/psco/cgi-bin/links.pl) and it seems to be used by the US Cours as well: https://ecf.azd.uscourts.gov/cgi-bin/ShowIndex.pl https://ecf.azd.uscourts.gov/cgi-bin/ShowIndex.pl
mfontani 6y ago
Sure: https://www.theregister.com/about/company/website/ https://www.theregister.com/about/company/website/
ainar-g 6y ago
OpenBSD uses Perl actively. https://marc.info/?l=openbsd-misc&m=159041121804486&w=2 https://marc.info/?l=openbsd-misc&m=159041121804486&w=2
megaframe 6y ago
Yes, I manage a set of tools and libraries written in perl that are pretty large and service the whole company. That said we're re-writing them all to Python so more people can contribute... Saddens me a little I like Perl, but I'll get over it.
ww520 6y ago
Yes. You’ll be surprised. Some of the biggest tech companies still use Perl in their critical components in production, and some of the initiatives are in recent years.
austincheney 6y ago
The primary use case of Perl is systems automation. Personally I prefer Node.js but most Linux distributions come with a Perl interpreter already installed and not Node. If you are working in an enterprise environment and for security reasons are not allowed to install software, which is common, you can still perform automation with Perl scripts.
lgl 6y ago
> Are there actually people that are still deploying new things in Perl? My personal experience: at one of my previous jobs we've had the need to find a support ticket system (preferably free) that was flexible enough to handle a few hundred email accounts with different signatures, headers, reply templates, queues, filters, and more for each individual account. At the time the "winner" was OTRS [0] [1], a system in Perl that is super flexible and had a free version (more recently renamed to community edition since it detached a bit from their enterprise version). It served us well enough that I have deployed it again on my current job when a similar but smaller need arose (both jobs in tourism industry). It's a pretty big and complex thing but does it's job well once configured correctly which does take a bit of work. > The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten. That can possibly be the case here since it is "old" (changelog lists the first public beta at 2002) but has had pretty much continuous development until this day. Any company trying to develop something like this these days would probably choose something else but I guess they're a Perl shop now. [0] - https://github.com/OTRS/otrs https://github.com/OTRS/otrs [1] - https://otrs.com/ https://otrs.com/
- roywashere 6y ago
  I actually worked for OTRS for some years. It is quite a remarkable company as it is creating an open source line of business software with a nice team of people and is making a sustainable business out of it. There are not much other software companies that managed to do this. Yes, you can call them open core now. But still many companies are using the community edition and are served well by it. I worked closely with the technical founder and he started the pre-decessor of OTRS in the 90s while working at SUSE, and yeah of course it was in Perl! I must say that working on the quite significant OTRS code base, with proper code conventions, 'modern' perl5 is not so bad. But when using third party libraries sometimes you'd see arcane language usage and there seems lots of magic involved... Also, the technical founder started https://zammad.org https://zammad.org -- the same idea but started in 2012 or so. So now it's Ruby! Modern perl5 is ok. But the ecosystem is slowly deteriorating.
  - yellowapple 6y ago
papito 6y ago
IMDB was written in Perl, notoriously. Seeing that the layout has not changed in ages, I can only assume it's still Perl. I'd imagine a bigger rewrite effort would have led to a more slick iteration on the UI, and it seems the legacy HTML templates are still baked in.
- yellowapple 6y ago
  DuckDuckGo's also written in Perl, and doesn't seem to have any trouble maintaining a reasonably-modern-looking UI.
  - Scarblac 6y ago
    Booking.com is also (notoriously) completely written in Perl.
  - hpcjoe 6y ago
    And their interview process is apparently, contribute a useful feature to the code base. Which, IMO, is brilliant.
- hpcjoe 6y ago
  Hmm ... don't conflate the presentation UI with the underlying language. I wrote my companies website (2 jobs ago) in Mojolicious (perl web framework), with a responsive UI, based in part upon bootstrap. Very modern (for the time) UI. All backed by a very fast implementation. IMDB seems plenty fast to me. UI isn't great, but that's more of a presentation layer design thing than a language thing.
  - papito 6y ago
    I am not actually talking about the quality of the UI - I am just pointing out that the UI seems to have been the same for years now, and I would think a rewrite from Perl would have changed that. Yes, you can totally swap out the backend, but IMDB codebase is old. HTML and the sprinkled JS (if you look at page source) is probably baked in deep.
frakkingcylons 6y ago
A lot of Debian's packaging tools are written in Perl.
mmcclimon 6y ago
Nearly everything at Fastmail is in Perl. Cyrus, which is the mail storage engine, is in C (and open-source), but everything else is Perl.
lilSebastian 6y ago
Perl is used extensively in the enterprise solutions we deliver for our client.
iso1631 6y ago
I wrote a quick perl script earlier today to push crt.sh results for a bunch of domains into slack. Took about 30 minutes, far less time than messing about with why pip has broken on my desktop yet again: Traceback (most recent call last): File "/usr/local/bin/pip", line 11, in <module> sys.exit(main()) File "/usr/local/lib/python3.5/dist-packages/pip/_internal/cli/main.py", line 73, in main command = create_command(cmd_name, isolated=("--isolated" in cmd_args)) File "/usr/local/lib/python3.5/dist-packages/pip/_internal/commands/__init__.py", line 96, in create_command module = importlib.import_module(module_path) File "/usr/lib/python3.5/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 986, in _gcd_import File "<frozen importlib._bootstrap>", line 969, in _find_and_load File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 673, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 665, in exec_module File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed File "/usr/local/lib/python3.5/dist-packages/pip/_internal/commands/search.py", line 18, in <module>
- b5n 6y ago
  I understand no one wants to deal with unexpected issues, especially when you're trying to get something done. Why not use virtual environments? You keep packages out of your system's python, and if you run into issues like above you can just recreate it: b5n:~/venv_dir$ python3 -m venv im_a_venv b5n:~/venv_dir$ . im_a_venv/bin/activate (im_a_venv)b5n:~/venv_dir$ pip install requests (im_a_venv)b5n:~/venv_dir$ pip freeze > requirements.txt (im_a_venv)b5n:~/venv_dir$ deactivate b5n:~/venv_dir$ python3 -m venv another_venv b5n:~/venv_dir$ . another_venv/bin/activate (another_venv)b@b5n:~/venv_dir$ pip install -r requirements.txt
  - anonymousCar 6y ago
    While experienced python devs will say, yeah that'd how you should do it. The problem is that python by default isn't using virtualenvs. Consider rust or is where you need to specify global installs.
  - 6y ago
rabbiveesh 6y ago
I write new things in Perl all the time. Deploying highly functional backend services using Mojolicious, a framework which is VERY actively developed.
lmiller1990 6y ago
My full-time job is working a codebase where the back-end is entirely written in perl. Codebase was started around 2014. This was probably a bad decision, the founder was a perl guy. Perl is not bad but no new codebases should ever be written in it imo. It's to easy to shoot yourself in the foot unless you know perl REALLY well. Moose is ok but a far-cry from any modern OOP system.
hpcjoe 6y ago
Lots of new things. Perl is an immensely powerful language. If you know how to write code well, it will be fully comprehensible by even casual programmers. Many orgs ship perl based tools as current, up-to-date products. Mellanox OFED is one I was using earlier today. My own github[1] has a plethora of perl projects. [1] https://github.com/joelandman https://github.com/joelandman
totalperspectiv 6y ago
It is alive and kicking in the bioinformatics community! I still think Perl is a much better tool for what some bash and python scripts are doing. Maybe Perl7 will remove some stigma and allow for people to use the tool instead of it being instantly dismissed.
wheresmycraisin 6y ago
Yes. The entire backend to my startup is Perl 5 (Mojolicious) + postgresql (albeit the postgresql part is obviously more important).
HelloNurse 6y ago
Last year I had to perform date arithmetic in C shell scripts on a locked down server (no way to install or compile programs and obsolete or missing utilities). I considered Perl, since it was the only scripting language interpreter, but the good enough (on paper) date handling libraries I found on CPAN turned out to require a far newer Perl 5 version that was available. I'm afraid that the best-case Perl solution would have been more difficult to write than the roundabout but reliable and easy to understand final solution (Oracle SQL functions executed through the command-line SQL*Plus client).

freyfogle 6y ago

yes, definitely. If you are manipulating text, Perl is great.

politelemon 6y ago

Yes... We have some high revenue, important contract type systems written a long time ago and maintained by the same subject matter experts who simply move the codebases (old and new) to newer systems and stacks. As you can tell, the SMEs have no interest in learning other things and so any new initiatives that require them to implement it is subject to their preferences.

hinkley 6y ago
Many places don’t support antifragility. Having an old system that nobody wants to rewrite may not be a reflection on the engineers. You’re an expert, and a rewrite is going to expose you to a lot of scrutiny. You are going to break things, when maybe you haven’t broken things in a long time and people like it that way. So when some day arrives where a new fad is hot and it’s hard to impossible to find Perl programmers, the will create a new team to rewrite it badly because now they have no other choice. And of course the new folks are going to screw up, but that’s just expected.
- gmmeyer 6y ago
  There's no need to rewrite a system that works and that you're not gonna change. While programming languages go out of fashion there will always be people who are capable of writing them. The median age of a cobol programmer has not changed in 20 years because more people keep learning the language. Demand in this case, will likely create its own supply.
  - hinkley 6y ago
    I tend to replace my car when it starts to show signs of future problems, not when I'm up to my eyeballs in repairs. We shouldn't really be treating software differently. The liability for a mission critical system that works but cannot be repaired climbs over time. Just because it works doesn't mean it isn't broken.
    - derriz 6y ago
      That analogy doesn't really work - software doesn't get worn out from interaction with users. If software is working and in use, then it's age doesn't matter. Evolution/flux is not the natural state of all software. I've seen plenty of business/enterprise software which has continued to provide business value for decades without structural or architectural changes.
      - hinkley 6y ago
        Lots of security patches and infrastructure are held hostage by breaking changes to APIs. Eventually you have to upgrade, and the longer you have put it off the more painful it will be. And as we've seen with old video games, there are lots of timing problems that you simply never encounter on the original hardware but are impossible to ignore on recent vintage hardware.
  - ChiranSoogoor 6y ago
    Wisdom is in not in spending years and millions rewriting billions of lines of cobol code into a new language and then rewriting that other language into another newer language and so on … what's the problem in maintaining what's already working?!!
- CountSessine 6y ago
  the will create a new team to rewrite it badly because now they have no other choice Given Perl’s legendary code-opacity and maintenance challenges, this kind of seems inevitable. After all, if you could at least read and decipher the old code, maybe you could reproduce it!
- yellowapple 6y ago
  > and it’s hard to impossible to find Perl programmers Which I'm finding harder to understand as I learn more languages. Yeah, every language has its differences and idiosyncrasies, but as long as you have access to docs (if not third-party resources like expert blogs or Stack Overflow) it's pretty straightforward to figure those out and be reasonably productive relatively soon. That is: a senior programmer should have enough background knowledge to be able to be productive on any language ("polyglot" shouldn't be a big deal), and a junior programmer won't typically have enough experience in any particular language to be definitively a "$LANGUAGE programmer". In either case, whether or not a programmer already knows the language before being hired is kind of a moot point. My current dayjob was the first time I had written any non-trivial amounts of Python, Javascript, or C# in a professional capacity in my whole career. Being productive on them wasn't terribly hard - it's just different syntax around a lot of the same concepts (and sure, there were also some new concepts - took a good while for me to wrap my head around async/await, for example, coming from a background of message passing between threads or processes or actors - but those can be learned). Usually the choice of programming language is far less significant as a barrier to one's understanding of a codebase than, say, the actual problem domain. Writing software for, say, a warehouse tends to necessitate knowing an awful lot about how warehouses work; whether or not you happen to know a given programming language is entirely secondary to whether or not you know the difference between a picker and a packer, or between a replenishment and a cycle count. Similar deal in medicine, or education, or manufacturing, or sales, or finance, or what have you.
  - hinkley 6y ago
    A former boss was fond of saying "Software is done when nobody is willing to work on it anymore." New people make idiomatic mistakes, and if the language isn't cool they expect more money. Recruiting people is harder, so you tend to get stuck with the people you have, and managers tend to bristle at that. Eventually a new language full of people who look like cogs is going to win out. I hate that this is true, but it is. I maintained a Python test harness for a while. No prior experience with Python. I mostly stayed out of trouble, in part because I set low expectations, tried nothing fancy. But it wasn't what I wanted to be doing, and not what I wanted the team to be doing. When I left they finally canned the entire thing.
- codr7 6y ago
  There are plenty of silly reasons to rewrite a piece of code, but language preference has to be one of the worst. Now that I think about it, that's actually a decent hiring test: Tell the candidate part of their job will be maintaining a small Perl codebase. If they can't deal with that without throwing a fit, I have no interest in working with them. It's a sharp tool, if you're not careful someone might get hurt. But professionals deal with sharp tools all the time, especially when it's the best tool for the job.

smaili 6y ago

IIRC Craigslist was written in Perl but that's the only high traffic site that comes to mind.

1-more 6y ago
I know some fantasy sports site was, maybe CBS? I had a UX designer colleague who had worked on that.
- hnlmorg 6y ago
  A surprisingly large number of fantasy sports sites are. Perl is everywhere, it's just not widely publicised because of the stigma attached to the language.
ori_b 6y ago
duckduckgo, as far as I recall.
petethered 6y ago
Duck Duck Go and Booking.com were/are Perl backends.
chubot 6y ago
I think they still write everything in Perl, and they employ Larry Wall (or they did several years ago, last I heard)
Twirrim 6y ago
The Amazon retail site is written in perl (at least the presentation layer still is, you can find mason references still in the HTML source if you go looking, don't know how much else behind it is in perl). https://metacpan.org/pod/Mason https://metacpan.org/pod/Mason (if you're not familiar with Mason)
- autarch 6y ago
  Actually, that's Mason 2. Amazon use(s|d) the OG Mason - https://metacpan.org/release/HTML-Mason https://metacpan.org/release/HTML-Mason

jpxw 6y ago

Yep, I know of one company still actively using Perl for a large part of its infrastructure. It has its use cases.

noja 6y ago
Booking.com?
- jpxw 6y ago
  Nope :)
  - deleted 6y ago
    [deleted]
paultopia 6y ago
are the use cases all really really fancy regexes?
- deleted 6y ago
  [deleted]
Diederich 6y ago
One that is definitely still using Perl in a very big way is https://www.ariba.com/ https://www.ariba.com/ Ariba isn't a household name, but it has deep and widespread connections to thousands of the largest companies in the world.
noema 6y ago
Are they named after a very large tropical rainforest?

nchelluri 6y ago

> Are there actually people that are still deploying new things in Perl? See https://news.ycombinator.com/item?id=23593835 https://news.ycombinator.com/item?id=23593835

1996 6y ago

I do. Efficient, cheap and stable. Ported to about everywhere.

smabie 6y ago
What do you mean by cheap? Also, perl is incredibly inefficient: it's even slower than Python. Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?
- kbenson 6y ago
  > it's even slower than Python. It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes. > Are you saying the language doesn't change much or that it doesn't crash? Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.
- 1996 6y ago
  - Efficient: from prototype to deployment, it's a matter of days. The choice of styles let people use paradigms they are familiar with, meaning they do things quickly. - Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage. - Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.
  - continuational 6y ago
    The reason that code written 20 years ago still runs fine is that they rolled back 20 years of changes!
    - 6y ago

nicoburns 6y ago

I believe MoveGB is running a perl backend.

triangleman 6y ago

I'm working through the Llama book, seems like a fun alternative to Python.

benbristow 6y ago

I used to work for a company that used Perl as their primary language. The codebase was millions of lines long, modules (pm files) with like 1000 methods and 10,000 lines, a total mess and it had 0 unit tests too. Almost beyond salvageable. Left a bit of a sour taste. They're trying to migrate to AWS but AWS don't even natively support Perl in their libraries. There's a few third party libraries in CPAN but nothing as comprehensive as what's available with official libraries for other languages. Nothing against the language but I don't know why you wouldn't use literally anything else nowadays. Python or PHP, JavaScript or even Ruby if you're looking for a dynamically typed language. AWS don't even support Perl.

ugexe 6y ago
Your opinion on Perl is based on one code base you worked at on one job?
- w0m 6y ago
  Honestly that's more than most I think. I've written tens of thousands of lines of perl professionally and I generally share the same opinion.
  - nchelluri 6y ago
    I've been writing (Modern) Perl for about 3.5 years and I disagree that Perl necessarily tends to unreadable code. I really don't think that's true at all. To quote myself from a recent discussion: I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ all the time], code linters, and so on) I think how you use a language plays a huge part in code maintainability. For instance, I've heard PHP get shit on pretty badly all around the web, but I've worked at PHP shops that had nice, clean codebases, and my current Perl codebase is, in many ways, nicely structured. That's not to say there aren't some hairy codepaths that could use refactoring, but I really think that kind of thing, again, can happen in almost any language.

Lammy 6y ago

> Are there actually people that are still deploying new things in Perl? Anecdote: I found this Perl image-hosting package a couple years ago as a self-hosted alternative to sites like Imgur, and I think it's great: https://framagit.org/fiat-tux/hat-softwares/lutim/tree/master https://framagit.org/fiat-tux/hat-softwares/lutim/tree/maste...

jhowell 6y ago

I think the US Courts still use Perl for Pacer (https://www.pacer.gov/psco/cgi-bin/links.pl https://www.pacer.gov/psco/cgi-bin/links.pl) and it seems to be used by the US Cours as well: https://ecf.azd.uscourts.gov/cgi-bin/ShowIndex.pl https://ecf.azd.uscourts.gov/cgi-bin/ShowIndex.pl

mfontani 6y ago

Sure: https://www.theregister.com/about/company/website/ https://www.theregister.com/about/company/website/

ainar-g 6y ago

OpenBSD uses Perl actively. https://marc.info/?l=openbsd-misc&m=159041121804486&w=2 https://marc.info/?l=openbsd-misc&m=159041121804486&w=2

megaframe 6y ago

Yes, I manage a set of tools and libraries written in perl that are pretty large and service the whole company. That said we're re-writing them all to Python so more people can contribute... Saddens me a little I like Perl, but I'll get over it.

ww520 6y ago

Yes. You’ll be surprised. Some of the biggest tech companies still use Perl in their critical components in production, and some of the initiatives are in recent years.

austincheney 6y ago

The primary use case of Perl is systems automation. Personally I prefer Node.js but most Linux distributions come with a Perl interpreter already installed and not Node. If you are working in an enterprise environment and for security reasons are not allowed to install software, which is common, you can still perform automation with Perl scripts.

lgl 6y ago

> Are there actually people that are still deploying new things in Perl? My personal experience: at one of my previous jobs we've had the need to find a support ticket system (preferably free) that was flexible enough to handle a few hundred email accounts with different signatures, headers, reply templates, queues, filters, and more for each individual account. At the time the "winner" was OTRS [0] [1], a system in Perl that is super flexible and had a free version (more recently renamed to community edition since it detached a bit from their enterprise version). It served us well enough that I have deployed it again on my current job when a similar but smaller need arose (both jobs in tourism industry). It's a pretty big and complex thing but does it's job well once configured correctly which does take a bit of work. > The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten. That can possibly be the case here since it is "old" (changelog lists the first public beta at 2002) but has had pretty much continuous development until this day. Any company trying to develop something like this these days would probably choose something else but I guess they're a Perl shop now. [0] - https://github.com/OTRS/otrs https://github.com/OTRS/otrs [1] - https://otrs.com/ https://otrs.com/

roywashere 6y ago
I actually worked for OTRS for some years. It is quite a remarkable company as it is creating an open source line of business software with a nice team of people and is making a sustainable business out of it. There are not much other software companies that managed to do this. Yes, you can call them open core now. But still many companies are using the community edition and are served well by it. I worked closely with the technical founder and he started the pre-decessor of OTRS in the 90s while working at SUSE, and yeah of course it was in Perl! I must say that working on the quite significant OTRS code base, with proper code conventions, 'modern' perl5 is not so bad. But when using third party libraries sometimes you'd see arcane language usage and there seems lots of magic involved... Also, the technical founder started https://zammad.org https://zammad.org -- the same idea but started in 2012 or so. So now it's Ruby! Modern perl5 is ok. But the ecosystem is slowly deteriorating.
- yellowapple 6y ago

papito 6y ago

IMDB was written in Perl, notoriously. Seeing that the layout has not changed in ages, I can only assume it's still Perl. I'd imagine a bigger rewrite effort would have led to a more slick iteration on the UI, and it seems the legacy HTML templates are still baked in.

yellowapple 6y ago
DuckDuckGo's also written in Perl, and doesn't seem to have any trouble maintaining a reasonably-modern-looking UI.
- Scarblac 6y ago
  Booking.com is also (notoriously) completely written in Perl.
- hpcjoe 6y ago
  And their interview process is apparently, contribute a useful feature to the code base. Which, IMO, is brilliant.
hpcjoe 6y ago
Hmm ... don't conflate the presentation UI with the underlying language. I wrote my companies website (2 jobs ago) in Mojolicious (perl web framework), with a responsive UI, based in part upon bootstrap. Very modern (for the time) UI. All backed by a very fast implementation. IMDB seems plenty fast to me. UI isn't great, but that's more of a presentation layer design thing than a language thing.
- papito 6y ago
  I am not actually talking about the quality of the UI - I am just pointing out that the UI seems to have been the same for years now, and I would think a rewrite from Perl would have changed that. Yes, you can totally swap out the backend, but IMDB codebase is old. HTML and the sprinkled JS (if you look at page source) is probably baked in deep.

frakkingcylons 6y ago

A lot of Debian's packaging tools are written in Perl.

mmcclimon 6y ago

Nearly everything at Fastmail is in Perl. Cyrus, which is the mail storage engine, is in C (and open-source), but everything else is Perl.

lilSebastian 6y ago

Perl is used extensively in the enterprise solutions we deliver for our client.

iso1631 6y ago

I wrote a quick perl script earlier today to push crt.sh results for a bunch of domains into slack. Took about 30 minutes, far less time than messing about with why pip has broken on my desktop yet again: Traceback (most recent call last): File "/usr/local/bin/pip", line 11, in <module> sys.exit(main()) File "/usr/local/lib/python3.5/dist-packages/pip/_internal/cli/main.py", line 73, in main command = create_command(cmd_name, isolated=("--isolated" in cmd_args)) File "/usr/local/lib/python3.5/dist-packages/pip/_internal/commands/__init__.py", line 96, in create_command module = importlib.import_module(module_path) File "/usr/lib/python3.5/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 986, in _gcd_import File "<frozen importlib._bootstrap>", line 969, in _find_and_load File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 673, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 665, in exec_module File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed File "/usr/local/lib/python3.5/dist-packages/pip/_internal/commands/search.py", line 18, in <module>

b5n 6y ago
I understand no one wants to deal with unexpected issues, especially when you're trying to get something done. Why not use virtual environments? You keep packages out of your system's python, and if you run into issues like above you can just recreate it: b5n:~/venv_dir$ python3 -m venv im_a_venv b5n:~/venv_dir$ . im_a_venv/bin/activate (im_a_venv)b5n:~/venv_dir$ pip install requests (im_a_venv)b5n:~/venv_dir$ pip freeze > requirements.txt (im_a_venv)b5n:~/venv_dir$ deactivate b5n:~/venv_dir$ python3 -m venv another_venv b5n:~/venv_dir$ . another_venv/bin/activate (another_venv)b@b5n:~/venv_dir$ pip install -r requirements.txt
- anonymousCar 6y ago
  While experienced python devs will say, yeah that'd how you should do it. The problem is that python by default isn't using virtualenvs. Consider rust or is where you need to specify global installs.
- 6y ago

rabbiveesh 6y ago

I write new things in Perl all the time. Deploying highly functional backend services using Mojolicious, a framework which is VERY actively developed.

lmiller1990 6y ago

My full-time job is working a codebase where the back-end is entirely written in perl. Codebase was started around 2014. This was probably a bad decision, the founder was a perl guy. Perl is not bad but no new codebases should ever be written in it imo. It's to easy to shoot yourself in the foot unless you know perl REALLY well. Moose is ok but a far-cry from any modern OOP system.

hpcjoe 6y ago

Lots of new things. Perl is an immensely powerful language. If you know how to write code well, it will be fully comprehensible by even casual programmers. Many orgs ship perl based tools as current, up-to-date products. Mellanox OFED is one I was using earlier today. My own github[1] has a plethora of perl projects. [1] https://github.com/joelandman https://github.com/joelandman

totalperspectiv 6y ago

It is alive and kicking in the bioinformatics community! I still think Perl is a much better tool for what some bash and python scripts are doing. Maybe Perl7 will remove some stigma and allow for people to use the tool instead of it being instantly dismissed.

wheresmycraisin 6y ago

Yes. The entire backend to my startup is Perl 5 (Mojolicious) + postgresql (albeit the postgresql part is obviously more important).

HelloNurse 6y ago

Last year I had to perform date arithmetic in C shell scripts on a locked down server (no way to install or compile programs and obsolete or missing utilities). I considered Perl, since it was the only scripting language interpreter, but the good enough (on paper) date handling libraries I found on CPAN turned out to require a far newer Perl 5 version that was available. I'm afraid that the best-case Perl solution would have been more difficult to write than the roundabout but reliable and easy to understand final solution (Oracle SQL functions executed through the command-line SQL*Plus client).