warn “Use of Perl has been deprecated.\n”;
October 20, 2016
It’s been just over a month now, since my last day as an employee of Booking.com. Which means it’s been just over a month now since I wrote my last line of professional Perl. This is worth celebrating!
Now don’t get me wrong. It’s not that I hate Perl. In fact, I’ve really enjoyed using Perl over the years.
The early yearsI still remember my first “real” Perl script, which I must have written in 1998 or 1999, with the help of legendary book, [*Learning Perl, 2nd Edition*](http://shop.oreilly.com/product/9781565922846.do). It printed invoices for the customers of my now-defunct dial-up Internet service provider, Future Internet Services, which I ran out of my bedroom at my parents' house in Goessel, Kansas.
Several years later, in 2006, I got a job at Network Management Group, Inc. in Hutchinson, Kansas, as a network engineer, tasked with installing their appliance-based SaaS email filtering service in the cloud. Due to some rapid turnover, within a few months, I ended up as the lead developer of the project as well. That is when I was really forced to learn Perl. And I loved it!
Jump ahead a few years to 2013. I was still working on the same project, the DoubleCheck Email Manager, but it had been acquired by eFolder, Inc. We had known for quite some time that Perl didn’t scale well for our e-mail processing work flow. Scanning e-mail consists of a lot of waiting for the network. Hundreds of DNS queries plus waiting for slow SMTP connections, adds up to a lot of CPU idle time. The only real way to address this problem with Perl is with the pre-fork server model, also used by projects like the Apache Web Server. For an application like ours which typically handled hundreds simultaneous connections on a single server, this basically meant Perl filled up the server’s RAM faster than Donald Trump fills up his 140-character Tweet size limit.
The Go programming language was getting a lot of positive press, and seemed to handle the asynchronous execution problem in a novel way. Plus, benchmarks were showing it to be faster than Node.js, especially under very heavy load.I bought a copy of [*Programming in Go*](http://amzn.to/2epduTh) near the end of 2014, and set out to take over the world! (It's a good book--I do recommend it if you're interested in learning Go!)
Not long after that, for reasons too boring to mention here, I decided to leave eFolder, and never Go never really took a stronghold there.
Just one more gig
But I was looking for work, and Perl was my most marketable skill. Booking.com was quite eager to hire me. My wife and I were also excited about the opportunity to live in and travel around Europe for a while, and Amsterdam seemed like a good base for that. So I accepted Booking.com’s offer, despite my growing indifference toward Perl.
After a year at Booking.com, it became apparent to me that it wasn’t a good fit for me (although not because of Perl). So I began looking for alternative employment, and accepted an offer at a subsidiary of eBay. Also with offices in Amsterdam. And also using a Perl stack, and therefore also eager to hire me for my experience.
So I bid adieu to Booking.com on September 16.
It’s time to Go
But shortly after accepting that position, I received another offer. A better offer! An offer to write Go, and to do it remotely, as I had for eFolder! I think it’s fair to say I was ecstatic to get the offer from Teamwork.com. Not only will I get to use Go, and do it remotely, but their company philosophy is also quite in line with my own. As one small example, Joel Spolsky, one of my favorite software development bloggers, is on their required reading list.
I will begin the new position on Monday.
And this is why Perl, for me, has been deprecated.
When did you last throw away unmerged work?
The last time you deleted or closed some unfinished work, what lead to that situation?
How clear is your product vision?
On a scale of 1 to "1000 songs in your pocket", how strong is your product vision?