| > ... you can have Go doing thousands of requests per second vs PHP doing hundreds of requests per second. > I know this because as an active PHP developer for over a decade I'm very much paying attention to that field of PHP. <insert swaggyp meme here> As an active PHP developer as well it sounds like you have no idea what you're talking about. > While you can use these tools you will almost certainly run into problems. Which tools are "generally not considered production-ready"? From what I'm seeing on the linked list of benchmarks... - vanilla php
- workerman
- ubiquity
- webman
- swoole I'd venture to bet all of these are battle tested and production ready - years ago now. As someone who has built a handful of services that ingest data in high volume through long-running PHP processes... it's stupidly easy and bulletproof. Might not be as fast as go, but to say these libraries or tech isn't production-ready is rather naive. |
* Vanilla PHP can't read anywhere near the same RPS as the others
* Using those results in removing the ability to use a large amount of the ecosystem. While if you used the correct language you would be able to use it's entire ecosystem.
* In my opinion, if you're using workerman or Swoole you've already realised the limitations of PHP and should be using another language.
This seems like a classic case of "if all you have is a hammer everything looks like nail"
> Might not be as fast as go, but to say these libraries or tech isn't production-ready is rather naive.
This strawman argument. Firstly, you admit my original point. Secondly, those aren't the tech in question and I notice you left off the tech in question. Roadrunner, FrankenPHP, etc. All the tooling that can make your average PHP app go faster.