I saw the link in Perl Weekly and thought it’d be good to share.
I work at Booking.com. We have millions of lines of Perl in production, with more than 500 devs working on the same repo. The unpleasant parts of the experience are infra problems, not Perl.
Oh interesting, booking(s) is still a lot/mostly Perl? I remember talking with people from the Dutch Perl community about 20 years ago, and I was wondering which direction booking has gone recently.
Yeah, it’s mostly Perl by volume (14M lines in our main repo). Over the last five years or so some important new services have been written in Java, and we have a smattering of Go (in some infra tools), Python (infra and data science) and NodeJS (honestly I don’t know where).
The direction the company wants to go into is to carve the Perl monolith into services (which will either be in Java or again Perl). This creates a lot of developer work and job security, and will possibly have other effects as well.
Booking is always named as one of the biggest (and successful) companies using Perl, but I can’t help but wonder if it’s just the Facebook effect. If you have enough manpower and smart people you get to your goal with every half-decent technology (not a slight against PHP or Perl), but the real question (and usually pointless) if they succeeded because of or despite the use of said language. I’m pretty much in the “doesn’t matter, but it probably helped at some point” camp.
Our new backend has been switched entirely from PHP to Perl. It’s much cleaner and flexible.
We are slowly moving all out .NET infrastructure to PHP and Node.js (I’m a career PHP developer) and I would love to know more about your decisions around moving PHP to Perl (and does Perl handle your CGI web requests [if any])?
We’re using Plack with Starman and Dancer or Mojolicious, which is usual practice. I’m not sure I can talk more because of NDA.
Perl really shines when used properly, with good code reviews every line is much more concise. The PHP codebase got really clunky and memory heavy as the size of the project grew.
I haven’t done any Perl in a decade, so my memory might be clouded by time. I really miss Mojolicious. It’s such a well thought through framework/library. Things really fit together. It’s not just a pile of features and it’s also not that heavy weight trying to do everything opinionated framework.
If someone wants to work on or does work on a web framework/library, even when having nothing else to do with Perl, I think it’s worthwhile to take a look. Hard to put into words, but it’s extremely well designed. It also does an excellent job of adapting to your needs if you just want to do a small single file project or a large software project. So it goes both the Sinatra and the Ruby on Rails way - not completely though for the RoR side.
Thanks for tip on the memory usage - its something I will keep in mind as we keep moving our codebase out of .NET and into alternative.
I am curious what prompted the change from .NET to PHP/Node.js? That level of change amounts to a rewrite, which usually takes a lot of time and resources.
Moving from .NET to PHP/Node.js was mostly due to common understanding of the languages and business needs. We are slowly trying to make discrete services from a monolithic Win32 application, and as a team we know PHP and Node.js more, so that’s what we’re doing.
Sounds like decisive step backwards!
Howso? We are moving some unstable spaghetti code with immense technical debt that no one in the department was apart of their inceptions (or countless iterations) to a planned codebase within the realm of familiarity and proficiency for the team.
Lots of people that reddit thread equating their subjective preference to an objective assessment of quality, “It’s better than python”, but in reality, developers went from perl to python in droves, not the other way around.
To attribute the current prevalence of python in machine learning libraries is missing the picture IMO. The shift started at least decade prior to that.
If I can add my two cents, I think it boiled down to overlooking the drawbacks that come with more power. there’s more than one way to do it vs there’s one way to do it, and preferably only one. Notice the ‘preferably’. The language has overlapping functionality within itself. Very quickly, the amount of things to know/memorize becomes a burden. It’s not that they are not useful, it’s just that they are too many. Python tackles this problem at its very conception. It is designed to give you enough power to do what you want while knowing very few syntax elements and language constructs. And it does so with a very reasonable cost in verbosity.
Maybe 20 years ago people would choose a language and specialise in it, this would not be a big deal. But at the rhythm people learn new stacks and libraries today, a language with more extensive syntax represents an extra investment in time that could be used elsewhere.
Scala has this problem too. Look at all this power, you can do a zillion things. But does one developer needs/wants to do all those things or is he fine with a small subset of it? To a single person, all the stuff he doesn’t use have no value. In practice, what python did well was settling for a reasonable set of features that strike a good balance between power and size. Guido has repeatedly rejected many things that other languages have and that would certainly be useful for some people. Not because he doesn’t find them useful, but rather to keep the language focus and philosophy.
I don’t think there is anything that perl should do to go after the success of other languages. The whole perl6 saga was a gigantic misstep. That won’t work. They should focus on what it does well and keep the community and ecosystem healthy. Although arguably, there are fewer and fewer things one wouldn’t have comparable ergonomics while using python instead. Or other language.
I’ve never used Perl in any more advanced than my own pet projects, but for me, Perl is just fun. It’s full of nice surprises, you can go just as far into the weeds as you want, and the culture around it appeals to me.
Of course, when there’s more than one way to do it, there’s a risk that each individual Perl hacker develops their own style that’s inscrutable to others. But I think that’s true, on some scale, in all languages, even those that go out of their way to prescribe how to use them.
I worked at a place with millions of lines of Perl, maintained by a couple dozen developers. That said, it was a very restricted dialect of Perl, with the vast majority of the “weird stuff” disallowed by custom-written code checkers. That was the only way to keep it maintainable. They preferred to hire only new graduates who they could train in their ways.
This is also how I write Perl. I call it PHP style, and most of my code can be copied and pasted between php and perl files with few changes needed.
I write scripts both in Python and Bash/ZSH but I feel like Perl 5 would be the sweet spot between those two languages for sys admin stuff.
I don’t know if Perl 6 serves that spot as well, but it may be an interesting choice for sys admins if it does.
I think Perl 6 serves that spot well in many senses except one: it doesn’t come preinstalled with virtually every real operating system.
Perl 6 has been renamed to Raku: https://www.raku.org/
I started a Perl project couple years ago and still writing it. There is no high-level language I know of that can match its stability, maturity, and install base. With care and avoidance of libs, it just works most of the time. As a spiritual being, I consider its author’s spirituality a huge asset as well.
For portability’s sake, again, I use PHP or SSI to glue it all to the web server.
Larry Wall writings or talks are always a great balance of tremendously goofy and tremendously insightful. I had not read this one before, but it’s great too. My favorite is this one.
Thank you! Great essay I enjoyed reading.
It’s probably the best option for text processing. Unicode, pcre, marpa.
Mojolicious is awesome.
We use it on my daytime job to fetch data from databases and text files and combine them.
Accessibility link: https://archive.vn/4MDSc