Ask HN: Why not PHP?

   "relatively recently"

   The key features of PHP 5.3.0 include:
 
    * Support for namespaces
    * Late Static Bindings
    * Lambda Functions and Closures

PHP has a sort of support for types, but while you can say that a function accepts a certain kind of object, you can't express that a particular function takes an int or a string. That's really pathetic. It's fine if you don't want a language with types -- many great languages don't have them -- but only PHP thinks that stupid half measures are acceptable.

PHP has had objects for some time, but it arguably didn't work well enough until their second try.

It's true that PHP makes it very easy to get at elements of the web request, but what I meant was that it is trapped in the content-generation phase. The Apache API is very sophisticated and gives you full control over the HTTP response cycle, but PHP throws all that way, and turns Apache into a dumb teletype. So every PHP script that needs to do authorization is written in this silly inside out way; first you start to deliver content, and then you check if you're allowed to actually do so. Whereas the right thing is to check authentication and authorization first, and then never even call your content script if the user's credentials didn't check out. Apache nicely separates this out with their Authentication, Authorization, and Content phases, but nobody told PHP. Other web frameworks don't have this problem either (I've used some web servlet engines written in Java, and they too avoid the brain-damage of doing it all in the content-generation phase.)

As for daemon scripts, I have no direct knowledge, but there aren't a lot of people who would suggest it's a great language for a daemon. Even fork() can be problematic in PHP. I wrote a system that tried to use it that way and we ran into all sorts of reliability problems (none of which I've ever encountered writing similar programs in Perl).

I may be more behind the times than others, since I happen to have worked on three different PHP projects that all started around 2003-4 or earlier (and are still chugging along). After being bitten in the ass by various broken features over the years, most of them have adopted a very limited subset of PHP (some even refuse to use objects, to this day), and I can see why.

I mean, PHP can be confused by something as simple as loading libraries from different script files. Rasmus' official advice to us was to have one "loader" script that included all the libraries in one shot. I find it hard to respect a language that has difficulties with things like this.

And Reddit is having a ton of scaling problems. The thing can't even support multicore . I'ts 2010 and you're telling me a langauge that can't handle multicore properly scales?

Oh. and don't mistake my python smack talk for defending PHP. PHP is the devil. I'm just not a fan of python.

"Python enabled us to create EVE Online, a massive multiplayer game, in record time. The EVE Online server cluster runs over 50,000 simultaneous players in a shared space simulation, most of which is created in Python. The flexibilities of Python have enabled us to quickly improve the game experience based on player feedback" said Hilmar Veigar Petursson of CCP Games.

So, yeah, you're completely wrong on all counts. And if you think multicore is the only way to do multiprocessing, you should probably go back to Operating Systems 101, or study the actual reasons why Python is or is not good for multiprocessing. The correct answer would have been the GIL and multiprocessing limited only to blocking IO calls.

At any rate, if you had actually used this for a real scaling problem, you would have realized that you spend 95% of your time waiting for IO on most web processes, so the choice of language is almost irrelevant so long as RAM usage doesn't get exceedingly high.