> The idea of a "working group" was discussed, but no process was established, > no "charter", no milestones. Edmond has been doing an amazing amount of work, > and I will repeat that I have huge respect for that effort. But if you drop > an encyclopedia on someone's desk and say "discuss", is it really surprising > that people don't know what to say?
As for the working group, it was created. AMPHP and Swoole officially responded to the proposal. Most of the discussions took place publicly. We can read them here: https://github.com/true-async/php-true-async-rfc/discussions I thought there would be more discussions, but the thing is that we don’t have any serious disagreements about the architecture. There are some doubts that the RFC won’t be accepted in its entirety, but that’s not a disagreement, rather secondary issues. This situation is largely expected, because this RFC doesn’t propose something new, but rather suggests bringing into the PHP core what has long been working in the form of "extensions". That’s why I’m not particularly surprised. The main obstacle, and the main doubts, are not about what needs to be done, but about whether it can be agreed upon. It would be good to discuss the global implications for PHP if this RFC is accepted. The global implications, or in other words a broader roadmap of changes that become possible and logical if the RFC is accepted. I tried to look at such implications in my article about multithreading. In an ideal world, I would like to be confident that everyone who will vote on this RFC clearly understands the foundation of what PHP is becoming: * a language oriented toward single-threaded concurrent execution, * with actors for multi-processor interaction. That’s how I see the end goal. A high-level language, with a high degree of abstraction over OS mechanisms. Without low-level elements. Without access to fine-grained tuning. As safe as possible and as simple as possible. A language with a built-in web server, socket server, and other types of servers. With asynchronous extensions enabled by default. The database connection pool should be available out of the box and look like the usual, familiar PDO classes, without significant changes. Single-threaded coroutines are a proven compromise between high complexity and ease of development. Actors are a proven, maximally safe approach to writing parallel code. None of these approaches is universal. On the contrary, they are all oriented toward the web. By voting for this RFC, you are voting specifically for a combination of these two approaches, which has long existed in Node.js (except for actors). It would be good if this were absolutely clear to all participants in the discussion.
