Perl has a fond place in my heart, though I don't use it for new things, but I still like it (some 20+ years ago I proudly wore a t-shirt with a square block of

Perl has a fond place in my heart, though I don't use it for new things, but I still like it (some 20+ years ago I proudly wore a t-shirt with a square block of perl code in the back that, should you type it and run it, would print a quote by Larry Wall. This shirt: https://www.flickr.com/photos/codepo8/489597488 https://www.flickr.com/photos/codepo8/489597488 - not my pic). That said, having had to deal with perl professionally a few times in the last 10 years, the biggest drawbacks I find in it for larger-scale projects are: - A lot of people are perl programmers, not programmers. I'm not tied to any language, believe in using the best tool for a job, and believe in using a language I'm not a big fan of if that makes it easier for a wider team. A lot of perl programmers I met don't feel the same and (wrongly, IMHO) think perl is the best language for every use case out there. - It's lacking in instrumentation when compared to other languages and VMs. It's more challenging to debug production problems with perl than with, say, C (and that should say a lot...) - There's no reliable way to limit resource usage of programs, which can be very bad when running on servers. Even worse if your perl code shares the server with other code. I think that's one of the reasons new Percona Toolkit tools are written in Go and not perl (but I could be wrong). It can be dangerous to run some perl scripts on a database server, for example. I suppose cgroups/containers/etc can help there, but only in a circuit-breaker way: I don't think there's an easy way for one to write perl code that can keep its resource usage under a predefined limit and still continue to work when the limit is reached. - Kind of like lisp, a lot of the power in perl also means that if a team is not tight and some coding standards are agreed upon, you end up with multiple custom languages sharing a codebase. Something like python takes care of this because there's usually a single way to do something. That also makes it more boring from a programming language perspective (to some people, to any extent) but as engineers our role is not to do cool, fun, and interesting things; we need to solve problems in a reliable and predictable way. Think of the people who carry a pager and will be waken up when there's a problem involving your code, even if that's you (your 3 AM self will thank your 2 PM self for not being clever with the hacks, trust me). That said, I'm happy the ecosystem seems healthy, I'm glad we have languages like perl that let you take a 25 year old script and run it today without changes. And reading all the people on this thread that work on perl, if it works for you and you get to make a living off of the language you love: cheers to you, and I'm sure there'll be job openings for perl programmers for at least another 2 to 3 decades.