PHP was built to parallelize requests, out of the box. It will use all of your cores automatically with no work on the developers part. It’s seemingly hard to find benchmarks comparing _modern_ versions of PHP not behind Apache to Node but once you get Apache out of the way of PHP7 the performance of modern PHP screams.

HHVM as you mentioned lost momentum when PHP7 largely met or surpassed its performance. That’s not a bad thing though, it just wasn’t hugely necessary anymore. The major upside is everyone gets the boost now, whereas HHVM was a nightmare to setup if you were not Facebook.

Beyond that, I truly believe the stateless nature of PHP requests is by far the easiest mental model to work with. As cross-request state is held exclusively and explicitly elsewhere (Redis, Memcache, SQL), it’s remarkably easy to reason about at scale.

This makes it easy to scale! Just throw another server on the load balancer and everything works. I work on a relatively large educational product, and we auto-balance up to 30+ servers during the week to handle a couple million users sending continuous streams of data, down to a minimum of 2 on weekends. It’s taken almost no consideration on the developers parts because of PHPs naturally stateless clean slate per page load model.

We also have a fair bit of Go in production, largely for CPU intensive operations. I love Go and use it for the majority of my newer personal projects. The major advantage to PHP that keeps it our primary language is the speed at which I can develop and iterate. The difference save/refresh vs save/recompile/restart/refresh makes in speed is not to be underestimated.

Myself as well as our lead dev have been using Go since before 1.x and we both still agree that PHP is better for rapid prototyping as well as just generally getting things out the door quickly.