Hello, Vincent. > The `spawn` keyword might disqualify this rfc, i talked to alot of php devs about this rfc and they all had a similar complaint about the keyword, maybe a keyword choice poll might help when the rfc voting goes live.
To have any kind of vote, we need multiple options. The keyword spawn is currently the best candidate. If you have a better one, I’m open to suggestions. > This whole rfc seem a little bit complex, which might ruin php codebase readability, let's keep things simple and concise, first impression matters for beginners and intermediate php programmers. I don’t understand how this RFC could make code harder to read. Can you give a specific example? And what exactly do you think would be difficult for beginner programmers? If you know a simpler way to express spawn function + await, I’m open to suggestions. > 3.) Let's not derive impression from java at this point, PHP might look similar to java but programmers hate java for a reason, overbloated way of doing simple things. First of all, I’m not taking inspiration from Java. This RFC is the result of a deep analysis of requirements, solutions, and implementation options — and I approach all of this primarily as a PHP developer, since PHP is where I have the most experience. I wouldn’t recommend paying attention to Java hate, because Java is one of the most widely used languages (probably second only to C). It’s a general-purpose language used across a broad range of domains. It’s also a language in which error research and use case studies are conducted — by some of the brightest minds. Ignoring the experience of Java just because of the illusion of “hate” would be shortsighted — that hate is more likely caused by the fact that there’s no such thing as a universal tool. As for Java Loom, its model is the closest to PHP — because of historical reasons. The second closest model is Python, which also has a similar history of adopting async features later. Both languages didn’t have built-in async from the beginning, which makes their experience particularly relevant to PHP. Go, on the other hand, was designed from the ground up for concurrency — that makes its lessons less applicable. And finally, the most important point: this RFC is exactly the way it is *because* it is designed for PHP, not for Java. For example, in Java you are always required to define a Scope. In Python, you always define a TaskGroup. Python has context managers to help simplify this. Java only offers explicit scope handling. This RFC gives developers the ability to write simple code without explicitly interacting with a Scope, while still benefiting from structured concurrency and coroutine control. And coroutine control is critical for frameworks and real-world projects. Without points of responsibility for control, you can’t write reliable PHP code or catch errors easily. If you think the Go approach is simpler — that’s a misconception. Go is not beginner-friendly. Go demands a deep understanding of async and strict discipline. Go and Rust developers (as shown in the study linked in the RFC) are very strict in their use of concurrency. PHP developers are used to a different style — PHP tends to forgive mistakes. Every part of this RFC exists not out of personal preference, but to solve real, practical problems. >
