u/Glittering_Bath3848

The PHP Foundation just ran their State of PHP survey (April 22–28, 2026) and I looked at the Q&A submissions, async dominated the conversation. Multiple submissions asking "when will async be OOB in PHP?", "why is PHP the only language without async?", "any plans to bring async to core? it's essential" and the top voted question was literally asking how many people are even using async libraries, with 58 upvotes.

That last part tells you everything. The most upvoted async question wasn't about a technical gap. It was asking if people are even using the libraries that already exist. Let that sink in.

The problem is already solved.

Amphp v3 with fibers looks like this:

$result = async(function() {
    return doSomething();
});

That's it. That is async PHP. It uses fibers (introduced in PHP 8.1) under the hood, it's non-blocking, it has a full event loop, and it has async-native clients for MySQL, PostgreSQL, Redis, HTTP, all written in pure PHP speaking the wire protocol directly over non-blocking sockets. Exactly the same way node-mysql2 and the pg library work in Node.js. No C magic. No runtime changes needed.

ReactPHP has been doing this even longer. The tooling exists. It's mature. It's production-proven.

"But PDO and mysqli block!"

Yes. And serious async PHP devs already dropped them, the same way serious Node devs don't use blocking database drivers. amphp/mysql exists. amphp/postgres exists. The migration path is the same as it is in every other async ecosystem and you use the async-native client. This is not a PHP-specific problem and it's not a reason to change the language core.

"But the ecosystems are fragmented!"

Were. Amp v3 essentially won. ReactPHP is still alive but Amp has the mindshare. And PHP 8.1 fibers gave everyone a common low-level primitive. This argument is stale.

So why do people keep asking for it?

Honestly? Three reasons:

Language pride. PHP gets dunked on constantly by Node and Go devs. "We need native async" is a clout-chasing response to that. People want to say "PHP has async too" as a gotcha without actually engaging with the ecosystem that already provides it.
They don't want to learn a library. They saw async/await in a JavaScript tutorial, it looked clean, and they want that exact syntax in PHP without doing any work. These same people would misuse native async just as badly as they'd misuse Amp if they bothered to learn it.
They've never actually needed it. The people genuinely building high-throughput async systems in PHP and HTTP servers, WebSocket services, concurrent API aggregators are already using Amp, Reactphp or Guzzle and they're fine. They're not the ones posting these threads. It's always people who want to sound like they're solving hard problems without doing the work.

The survey proves this. The loudest async voices are asking if f***** people use async libraries and not reporting problems with them. Nobody shipping real async PHP is in that survey crying about missing core support.

What native async would actually give us:

async/await keywords instead of async() function syntax sugar
It being in the manual so it feels "official"
Not having to composer require anything

That's the complete list. Those are not nothing, but they are also absolutely not the compelling technical argument people frame them as. You are asking the core PHP team to take on permanent language complexity and maintenance burden so you don't have to type composer require amphp/amp.

The uncomfortable truth

If you submitted one of those survey questions and you have never shipped a production service using Amp or ReactPHP, you are not advocating for a technical improvement. You are advocating for your comfort zone and your ego.

Learn the library. Build something real with it. Then come back and tell me what's actually missing.

Downvote this if you don't like post, go ahead I don't care and will not reply to any comments..

Dami kong nakikitang feeling mga feeling freelancer sa mga programming groups sa FB.