Someone needs to take jwz aside...

Pedro Figueiredo me at pedrofigueiredo.org
Wed Apr 20 20:18:31 BST 2011


On 20 Apr 2011, at 19:08, Joel Bernstein wrote:

> On 20 April 2011 18:45, Pedro Figueiredo <me at pedrofigueiredo.org> wrote:
>> 
>> He might or might not have a point. The truth is, as someone working in a Java shop where the core business is writing games, as long as this happens whenever we need a web server for a non-core service, it's PHP, because Ops don't even have to think about it.
> 
>> From the outside, it looks like the thing that makes PHP apps easy to
> deploy is that they depend only on pure-PHP code they bundle or on the
> standard library - there *is* no dependency chain there.

It's not only that, it's more that to get a fully-featured PHP environment, the server build script reads

yum install apache
yum install php

Get to that point with Perl and you win.

I wrestled with this a couple of years ago (even gave a talk about it at YAPC::EU, http://www.slideshare.net/pfig/perl-in-teh-cloud) and it's really a lot of work, every time you need to update something, you either

a) rebuild the AMI

b) update the snapshot which your EBS volumes are based on

c) fiddle with your local::lib install or Shipwright vessel.

You know what I do with Maven? I update the version number in the file that drives it. Boom.

I have got to the point with Maven where I can have it run tests and drive CI of Perl modules and apps, but I simply don't have the time to make it grok Perl to the point of dealing with dependencies, etc.

> 
>> And as for the Java bloat, who cares, it's all packaged nicely and automagically in the JAR, and there's Maven to deal with the dependencies. File size of said JAR doesn't mean squat, we're not on 33.6kbps modems anymore (and please don't mention Shipwright - which I use personally, btw - that still is several orders of magnitude more work than running 'mvn deploy'.
> 
> For *apps*, that's a reasonable approach, while for libraries it adds
> bloat since each library packages its own copy of its common
> dependencies -

No they don't.

> 
> I haven't used it a great deal but PAR lets us distribute apps with
> their dependencies, I don't really know how well it works for
> sysadmins though. There's also App::FatPacker which seems very nice
> (this is what cpanm, perlbrew etc use) but presumably only works with
> pure-Perl dependency chains?
> 

The problem lies well below this: vendor-supplied Perls are shit, so you always have to work with your own.

> myapp.pl? I can see that you've still got to ensure that the right
> versions of any system libs your PAR contents link to are present or
> expect a segfault, but I suspect Java may not cope well in that
> situation too?

Funny you should say that, I can't remember a single instance of having to have a given external (e.g., C) library in a box to run our Java stack (and we use quite a lot of 3rd-party Java libraries).

Cheers,

Pedro


More information about the london.pm mailing list