in reply to Re^3: PHP over perl
in thread PHP over perl

The big difference there is that mod_php is able to restart the PHP interpreter for each request. (You can do something similar with mod_perl, as I've pointed in the past, but no ISP is going to bother.) And from a security perspective, mod_php runs as the web server user, just like mod_perl does.

Frankly, I'm not sure why people are still talking about this, when so many cheap ISPs support FastCGI. You can run PHP or Perl on FastCGI without any security concerns beyond those of CGI. If you run a dedicated server, you can use mod_php or mod_perl for more features. Seems like a done deal to me.

Replies are listed 'Best First'.
Re^5: PHP over perl
by Your Mother (Archbishop) on Feb 10, 2009 at 21:12 UTC
    I'm not sure why people are still talking about this

    Both are just unsuitable for the kind of stuff that, I'd guess, 99% of web development in the wild really is.

    modperl in the right configuration is not supported anywhere I've ever seen. I have had problems even requesting trivial/required Perl changes from budget hosts. I can't imagine one that would setup modperl for less than a hundred or two a month.

    fastcgi is unsuitable because developing live would involve: 1) Make a change, 2) Watch your server stop working for 2-5 minutes because it had a syntax error and that's how it's configured, 3) Try this for two hours until you *curse* the names of perl and fastcgi, 4) Try PHP, see results instantly, never look back.

    fastcgi b) do your development at home on a dev box, not live, like you should. Now you're back to having to be a sysadmin/webmaster to setup your server(s) and environment. You're a professional again and not a normal user who reaches for PHP.

    I'm on your side. modperl is great, fastcgi + perl is great, and I would *love* Perl to take the web back at the entry level but PHP fills this niche better so far. This is why I was initially excited about the modperlite stuff but without at least persistent DB connections, it still probably loses to PHP.

      That sounds like a problem with a specific FastCGI configuration to me. Since I don't use it, I can't suggest how to fix it, but there's no way that's an intrinsic problem.