It's not helpful to be faster than the language that the parent implied wasn't fast enough.

I think the parent's point was that if the startup's raison d'etre involves "chew[ing] through TBs of data every hour", then choosing a language that can do that 10x faster than another might have a tremendous impact on cost and so the company's value. It might be the difference between successful or not.

More generally, "it depends".

It depends on the definition of "just fine" really, not to be argumentative. I've written quite a few algorithms processing big numbers (e.g. numbers with digits in the megabytes) and PHP struggles, where other languages like GO are several times faster and often far more easy to parallelise whereas with PHP if I want to try and use the multiple cores my CPU has, I need to look into pthreads or worse, write worker scripts that I execute with backticks or curl, it's clunky for that use-case. I wouldn't even know where to start thinking about how to run my algorithms in the GPU with PHP.

I say this as primarily a PHP developer in my paid profession, and PHP is my go-to for any kind of web development or if I want to prototype an idea - it's a very expressive and intuitive language but there are always use-cases that any language is decidedly unsuited to, even if it's "technically" capable. I wouldn't build a website in native C, even though I know it's "technically" possible for example.

I think to OC is not well formulated: If you're selling a web app or web SAAS, any language the founders know best is the best. Any other stuff, it is not always the case (but it might be!)

I suspect they meant the kind of heavy math that the PHP 8.x JIT is trying to improve performance for.