We had the "What language?" talk when we started work on Cloudmin, as well as when we began planning some web services. Perl ended up on top in both cases. Admittedly, we have a historic codebase of several hundred thousand lines of Perl, but we've both worked in Python at least as much as Perl in the past several years and there is a version of our API in Python that we could have started from. We weren't forced to choose Perl for legacy reasons, but we chose it, anyway.
We're pretty much agnostic about languages; we prefer dynamic languages, but not much beyond that. Our website is running on Drupal and several custom modules in PHP. We'll be adding those afore-mentioned web services via frontend PHP code, but the backend will be Perl. Haskell might make an appearance at some point in the future for concurrency work where performance matters, but for now, Perl is plenty fast and has reasonable concurrency mechanisms for our needs.
So, we're still cranking out tens of thousands of lines of Perl every year, and will be launching a couple of new products in the next six months also written in Perl.
But, I will mention that our products directly and easily support PHP, Ruby on Rails and Django deployments, but not Catalyst. And it's because we're simply not hearing requests for Catalyst from paying customers. Maybe the Catalyst developers are more old-school and don't trust a control panel (even one written in Perl), or maybe there's a helluva a lot more PHP and a handful more Ruby on Rails and Django developers out there (note that PHP developers using our software outnumber RoR and Django developers to a degree that makes the latter two practically noise in the signal). So, realistically, I have to agree. Perl is a niche language for new developments, but then again, so are Python and Ruby.
We're pretty much agnostic about languages; we prefer dynamic languages, but not much beyond that. Our website is running on Drupal and several custom modules in PHP. We'll be adding those afore-mentioned web services via frontend PHP code, but the backend will be Perl. Haskell might make an appearance at some point in the future for concurrency work where performance matters, but for now, Perl is plenty fast and has reasonable concurrency mechanisms for our needs.
So, we're still cranking out tens of thousands of lines of Perl every year, and will be launching a couple of new products in the next six months also written in Perl.
But, I will mention that our products directly and easily support PHP, Ruby on Rails and Django deployments, but not Catalyst. And it's because we're simply not hearing requests for Catalyst from paying customers. Maybe the Catalyst developers are more old-school and don't trust a control panel (even one written in Perl), or maybe there's a helluva a lot more PHP and a handful more Ruby on Rails and Django developers out there (note that PHP developers using our software outnumber RoR and Django developers to a degree that makes the latter two practically noise in the signal). So, realistically, I have to agree. Perl is a niche language for new developments, but then again, so are Python and Ruby.