On Sun, Jun 28, 2026, at 8:25 AM, Michael Morris wrote: > So, Alex and Rowan have started kicking around > containers/modules/whatevers again. And I've advocated for the concept > and been looking around for a way to accomplish it, and I found one, > then I read something that made me want to cry. > > You see, the PHP True Async RFC can do containers without being > changed. Well, more specifically, it can be done in userland with that > RFC included in the runtime. For review: > > https://wiki.php.net/rfc/true_async > > A lot of the criticism aimed at that RFC was, what would we ever use > this for? I myself didn't send any posts but that's what I was thinking > as I watched the debate over it a few months ago. > > The author has a github for the RFC and its code: > > https://github.com/orgs/true-async/discussions > > What got me to tear up a little bit, and made me angry, was this post. > > https://github.com/orgs/true-async/discussions/32 > > Particularly this: > >> Will the TrueAsync RFC be put to a vote within the coming year, or at least >> for PHP 8.7? >> Answer: No, it will not. There is a 90% chance the RFC will not be accepted. >> >> The main reason: the project has no support, not even at the level of its >> underlying philosophy. > > Folks, I'm going to be blunt. If you want PHP to be the next COBOL, > this is how you go about it. COBOL went from one of the more important > languages out there in 1980 to a joke by 1995. PHP can fall just as > fast. We've all seen the "PHP is dead" threads on LinkedIn. Knives are > out. > > Async calls are a part of every other language now. This is a missing > feature, and a major one. Edmond Dantes put a huge amount of work into > this, and for what? > > COBOL didn't get Object Oriented features until the late 90's. By then > it was too late. Coders had moved on. No one was learning it out of > college, just people maintaining it. > > I've said this before, but PHP brought me back into coding. I was able > to make a career, first out of bb boards, then WordPress and I finally > moved beyond that. I'll be forever grateful to the efforts of the > people here. You have changed my life. I've never claimed to be a > master coder with even 1% of the knowledge and expertise of the people > who maintain the language here. That's why I don't post a lot, because > I'm too stupid for most of the conversations. But I do bring the > perspective of someone who actually uses the language. I hope that's > worth something. > > I do remember typing Dantes' work should be the centerpoint of PHP 9, > not part of a point release. Even if it is fully backwards compatible > in its own right, it is still a sea change moment for the language > should it be adopted. > > I can understand the hesitation of adopting something this major. > People remember the PHP 6 unicode disaster well. But there was never a > fully working implementation of PHP 6. Async has a working > implementation. There's rough edges, but there's something here. > > Change is scary, but it's the only constant. Async operation is the > norm now. Object Oriented Code had become the norm by 1995. COBOL > ignored it, and died as a result. Will PHP do the same now?
As with the generics RFC, there is a very, *very* important distinction that must be made between: "I don't like this feature" and "I don't like this implementation of this feature." Erased generics just got voted down. But most of the feedback made it very clear that generics are wanted, we just don't want erased generics. A working reified generics implementation that had acceptable performance would likely pass overwhelmingly. Similar with async. I don't think anyone here is opposed to PHP having native async support. The disagreement is on how important it is (ranging from nice-to-have to life-or-death), and whether this particular implementation is the "right" one. The issue with Ed's True Async work isn't that it's async. It's that it was absolutely massive, championed by a single person with no reputation in the community yet, made hundreds of design decisions with far-reaching impact, and the author was highly selective about which feedback he accepted. Folks couldn't keep up with it, even though there were many parts of it I really really liked. I do think we need to have a proper working group (a la Ben's proposal) that can work on designing an async model collaboratively, with an emphasis on safety and keeping devs from shooting themselves in the foot. I want to see good async in PHP, for some not-yet-consensus-formed definition of "good." Don't confuse "this is not the async we're looking for, done in a painful process" with "we don't want async at all, ever." The first is what happened. The second is simply untrue. --Larry Garfield
