On Tue, Mar 24, 2026, at 5:08 AM, 沉默领域、 wrote: > Hi internals, > > > I'm a developer who uses both Java and PHP regularly. I'm writing > because I care about PHP's future. > > PHP's strength has always been simplicity and pragmatism. But since > PHP 7 and especially PHP 8, we've been adding "enterprise features" > (typed properties, attributes, property hooks) that make PHP more like > Java – without achieving Java's type safety or ecosystem. > > I believe PHP should refocus on what made it great. Here are four > pragmatic directions: > > --- > > 1. Stop Chasing Java > > Every "enterprise feature" pushes developers like me toward Java. Not > because Java is better, but because if I need enterprise complexity > anyway, I'd rather use a language designed for it. > > PHP cannot beat Java at its own game. But it can beat Java where it > matters: rapid prototyping, simple deployment, web-native development, > low learning curve. > > Please keep PHP simple. Keep it pragmatic.
This accusation has been thrown at PHP every few months since PHP 5.0 came out (which did indeed ape Java 2 for much of its OOP syntax and behavior). It's really a farcical misunderstanding of language design, "enterprise features," and "pragmatism." Many of the features added in the 8.0+ era are simple syntactic sugar to reduce typing. Is that "enterprise?" Typed properties greatly reduce the amount of error handling needed, and the amount of tests needed. Is that "enterprise?" Property hooks vastly reduce the need for boilerplate code, making it faster and easier to bang out code that is forward-compatible. Is that "enterprise?" The programming language community at large keeps learning, and has learned a ton since the 90s. One thing it has learned, but many developers have not, is that "code that finds errors for you at compile time" is NOT an enterprise feature. It's an everybody feature, which is why virtually every untyped language has had some form of types added to it, in various ways. (PHP directly, Python via unenforced annotations, Javascript via TypeScript, etc.) > 2. Add Practical Array Helpers > > PHP is a web language – 90% of what we do is manipulate arrays. Yet > basic operations are still verbose: > > ```php > // Current > $names = array_values(array_filter($users, fn($u) => $u->active)); > $first = count($names) > 0 ? $names[0] : null; > > // Proposed > $names = array_pluck($users, 'name'); > $names = array_where($users, fn($u) => $u->active); > $first = array_first($users); > $grouped = array_group_by($users, 'role'); > $compact = array_compact($data); > > These helpers would make everyday code cleaner without adding > complexity. You may have noticed that a number of array and string helper functions have been added in recent years. If there are more that you feel should be, RFCs are welcome. Just adding an array function is probably one of the simplest technical RFCs to write. > 1. Improve Performance > > Performance has always been a strength. Keep optimizing: > > • JIT for real-world web workloads > > • Reduce memory allocation in array operations > > • Make OpCache smarter All of these are happening, to the extent possible. > 1. Provide Built-in Concurrency (Without Complexity) > > Concurrency is the biggest missing piece. But instead of complex > async/await or coroutines, consider a simple worker management API: > > php > $server = new WorkerServer(); > $server->onWorkerStart(fn() => loadApp()); > $server->onRequest(fn($req) => handle($req)); > $server->start(4); > This would: > > • Run standalone: `php server.php` – no nginx, no PHP-FPM > > • Keep process isolation (each worker is separate) > > • Allow resource initialization once per worker > > • Give developers control without new concepts > > Why not just use FrankenPHP? FrankenPHP is excellent, but requires an > additional binary and new deployment workflow. Many developers just > want a simple, built-in way to run their app without configuring two > services. You may not have noticed, if you're new to the list, but there has been an extensive and ongoing discussion of improved async support, with a lot of focus on how to make it easy to use right and hard to use wrong. Because that is actually a really, really hard problem space. "Simple worker management" is not actually simple, when you dig into it. There's a lot of things that can go wrong, and designing it (both the code and the APi) such that it's hard to have things go wrong is itself really hard. That's why it's going on over a year now. Rest assured, there's an awful lot of people that really want good async/workers/etc. But it's nowhere near as easy as you think, or it would be done already. (See also: generics.) --Larry Garfield
