Re: PHP True Async RFC Stage 4

On Mon, 6 Oct 2025, Larry Garfield wrote: > On Mon, Oct 6, 2025, at 1:50 PM, Edmond Dantes wrote: > > > Of course, you might say that there are simple websites for which FPM > > is sufficient. But over the last two years, even for simple sites, > > there’s TypeScript — and although its ecosystem may be weaker, the > > language may be more complex for some people, and its performance > > slightly worse — it comes with async, WebSockets, and a single > > language for both frontend and backend out of the box (a killer > > feature). And this trend is only going to grow stronger. > > > > Commercial development of mid-sized projects is the only niche that > > cannot be lost. These guys need Event-Driven architecture, telemetry, > > services. And they ask the question: why choose a language that > > doesn’t support modern technologies. Async is needed specifically for > > those technologies, not for FPM. > > We must have a different definition of mid-sized, because FPM has been > used for numerous mission critical large sites, like government and > university sites, and has been fine. And such sites still benefit > from faster telemetry, logging, etc. > > Regardless, we can quibble about the percentages and what people > "should" do; those are all subjective debates. > > The core point is this: Any async approach in core needs to treat the > FPM use case as a first-class citizen, which works the same way, just > as reliably, as it would in a persistent CLI command. That is not > negotiable. > > If for no other reason than avoiding splitting the ecosystem into > async/CLI and sync/FPM libraries, which would be an absolute disaster. I also agree with this. I tried reading the RFC today, but I ran out of time. It is *59* page printed (I didn't). I think we need to be very careful that we do not introduce a feature that allows our users to run into all sorts of problems. The symantics of such a complex feature are going to be really important. Especially about reasoning in which direction the code runs and flows, and how errors are treated. I recently read https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ which seems like an entirely sensible way of proceeding. Although the title talks about Go and its problems, the "Structured Concurrency" approach is more of a way of doing concurrency right, without the possibility of our users getting into trouble. I don't think the RFC as-is is close to this at all — but I have mostly skimmed it so far. I would also believe that discussion how this should work would work better with a group of people - preferably in real-time - and not as an idea and implementation of a single person. I know others have been reviewing and commenting on it, but I don't think that's quite the same. Concurrency in all its forms is a complex subject, and we can't really get this wrong as we'll have to live with the concepts for a long time. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social