Also, it's a little obscure for languages like PHP where we're unused to making architecture/implementation distinctions, but if HHVM is good then PHP is good. It runs the same core language as php.net. To the extent we don't, it's likely to be a bug these days. I think HHVM is a better implementation of that language than php.net, but I am biased, and that isn't the point of the talk. We're also chipping away at running other popular programs, extensions and all: http://www.hhvm.com/blog/?p=875

Edit: transposed sentence

I've heard this argument before, but it's important to realize that Facebook was able to use standard PHP up until the point when they had roughly 500 million users. Unless your site has a half billion users you can't compare your use case to Facebook's.

As far as I can tell, only 3 is obviously something that only affects whether you can use the language once you have a certain number of users. The first two are really about changing the language.

And if we're talking about consumer products like facebook, it doesn't even say anything about how fast your programming language is since performance is dominated by database access time.

At best, we can try and claim that Facebook found PHP to be insufficiently expressive/safe/suited for them once they had X number engineers making Y number of changes per day.

Maybe they really could "move fast and break stuff" with 200+ engineers trying to commit to a vanilla PHP codebase.

If I make a function meow(MyClass $meow) { } it will throw errors if anything other than a MyClass is given to it, including NULL.

This will only accept an object that is_a MyClass. It can either implement an interface MyClass, extend an abstract MyClass, extend a regular class MyClass, or be the actual object MyClass.

Namespaces have nothing to do with this, other than you being able to use the "use" statement at the top to alias it.

As a matter of fact Facebook would probably have run into the same problems if they had used Ruby or Python. These problems are problems of massive scale most of us will never face. Twitter had problems running on Ruby/Rails and i bet theres a case to be made for Python too. All this says is that at the scale level of facebook you will encounter the limits of dynamic typing scripting languages, but its not a problem with PHP per se and also not a problem that should hold anyone back from choosing php/ruby/python because its premature optimization.

    >At this point we almost need to stop saying facebook programs in PHP

Also, your TL;DR is a flat out lie.