4 ms·

> Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run

by bkanber 10y ago

> Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once. I mean, you're not reinitializing it, and it's not exactly slow. And when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere. > where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours I'm not really sure what you mean by that. Write a method, write tests for that method. Just because PHP has weird type coercion issues doesn't mean you can't be diligent about the types that you use. And of course tools like PhpStorm understand docblocks, annotations and PHP types and classes and basically does the same thing that a compiler does, it'll show you big honking type errors if you ask it to, it'll even stop you from committing broken code if you use that option. > Sure, a lot of people have done a lot of quite cool projects in PHP, but I would much more benefit that to the lower barrier to entry I don't know about that. Low barrier to entry gets you a lot of crummy projects. In my experience PHP is a lot easier to manage and maintain in production, and that's a huge advantage to companies and products with small teams.

Tehnix 10y ago
>when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere It's just as easy to scale with other languages, you would keep the data that needs to be persisted in a DB. The benefit comes from things that does not need to be persisted, like resource pooling, memoization, config loading etc. > > where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours >Write a method, write tests for that method Exactly, I need to write tests for things that are trivially verifiable by a compiler. And I'm not just talking about type coercion (which is a bad thing), but also missing function parameters, wrong parameters, missing initialization of variables etc etc. These are runtime errors and you either have to write tests to catch them (hence visit very code block) or manually try and reach them. Some IDEs, like PHPStorm, can you get pretty far though. >Low barrier to entry gets you a lot of crummy projects As someone else mentioned in another comment, 1% of PHP projects succeeding is still a lot more than 20% of Haskell projects. >PHP is a lot easier to manage and maintain in production Except for when you need to scale. Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory for a PHP site to really run performant, adding quite an overhead to any production setup you'll get into.
- combatentropy 10y ago
  Look, if you want to use something other than PHP, don't let me get in your way. However, if PHP is one thing, it is fast and always has been. > Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory We don't use any of that. We don't even use database connection pooling. Every request has to reopen the database. Every request has to reopen an LDAP connection to Active Directory for authentication. We are still on PHP 5.3 and we aren't using an opcache. We are using the memory-hungrier mod_php instead PHP-FPM, and we are using the slower, memory-hungrier Apache prefork instead of its newer event MPM. We are also running PostgreSQL on the same server. And yet PHP is connecting to the database over the slower network instead of UNIX domain sockets. Every request takes just a split second. The server's processor is running at 1-2%, with about half a gigabyte of RAM in use, a lot of which is probably the database. All those inefficient design decisions are artifacts of history that I hope eventually to revise out --- except for connection pooling, which I've read has its own problems. On my personal website I've been able to choose the newer and better things, but none of them were really more work to set up: Apache event MPM, Unix domain-socket connections, PHP-FPM, and PHP's OPcache.

by bkanber 10y ago

Tehnix 10y ago

>when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere It's just as easy to scale with other languages, you would keep the data that needs to be persisted in a DB. The benefit comes from things that does not need to be persisted, like resource pooling, memoization, config loading etc. > > where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours >Write a method, write tests for that method Exactly, I need to write tests for things that are trivially verifiable by a compiler. And I'm not just talking about type coercion (which is a bad thing), but also missing function parameters, wrong parameters, missing initialization of variables etc etc. These are runtime errors and you either have to write tests to catch them (hence visit very code block) or manually try and reach them. Some IDEs, like PHPStorm, can you get pretty far though. >Low barrier to entry gets you a lot of crummy projects As someone else mentioned in another comment, 1% of PHP projects succeeding is still a lot more than 20% of Haskell projects. >PHP is a lot easier to manage and maintain in production Except for when you need to scale. Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory for a PHP site to really run performant, adding quite an overhead to any production setup you'll get into.

combatentropy 10y ago
Look, if you want to use something other than PHP, don't let me get in your way. However, if PHP is one thing, it is fast and always has been. > Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory We don't use any of that. We don't even use database connection pooling. Every request has to reopen the database. Every request has to reopen an LDAP connection to Active Directory for authentication. We are still on PHP 5.3 and we aren't using an opcache. We are using the memory-hungrier mod_php instead PHP-FPM, and we are using the slower, memory-hungrier Apache prefork instead of its newer event MPM. We are also running PostgreSQL on the same server. And yet PHP is connecting to the database over the slower network instead of UNIX domain sockets. Every request takes just a split second. The server's processor is running at 1-2%, with about half a gigabyte of RAM in use, a lot of which is probably the database. All those inefficient design decisions are artifacts of history that I hope eventually to revise out --- except for connection pooling, which I've read has its own problems. On my personal website I've been able to choose the newer and better things, but none of them were really more work to set up: Apache event MPM, Unix domain-socket connections, PHP-FPM, and PHP's OPcache.