Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130436
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 24 Mar 2026 14:02:23 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <a67cacfc-7ce0-4d20-a39a-2c51d43aaf21@app.fastmail.com>
In-Reply-To: <tencent_D07F06F5B18B1450B922355C06A3ED7E4107@qq.com>
References: <tencent_D07F06F5B18B1450B922355C06A3ED7E4107@qq.com>
Subject: Re: [PHP-DEV] [RFC] Four Pragmatic Directions for PHP: Simplicity, Arrays,
 Performance, Concurrency
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Mar 24, 2026, at 5:08 AM, =E6=B2=89=E9=BB=98=E9=A2=86=E5=9F=9F=E3=
=80=81 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 =E2=80=93 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 ca=
me out (which did indeed ape Java 2 for much of its OOP syntax and behav=
ior).  It's really a farcical misunderstanding of language design, "ente=
rprise 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 boilerpla=
te code, making it faster and easier to bang out code that is forward-co=
mpatible.  Is that "enterprise?"

The programming language community at large keeps learning, and has lear=
ned 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 NO=
T an enterprise feature.  It's an everybody feature, which is why virtua=
lly every untyped language has had some form of types added to it, in va=
rious ways.  (PHP directly, Python via unenforced annotations, Javascrip=
t via TypeScript, etc.)

> 2. Add Practical Array Helpers
>
> PHP is a web language =E2=80=93 90% of what we do is manipulate arrays=
. Yet
> basic operations are still verbose:
>
> ```php
> // Current
> $names =3D array_values(array_filter($users, fn($u) =3D> $u->active));
> $first =3D count($names) > 0 ? $names[0] : null;
>
> // Proposed
> $names =3D array_pluck($users, 'name');
> $names =3D array_where($users, fn($u) =3D> $u->active);
> $first =3D array_first($users);
> $grouped =3D array_group_by($users, 'role');
> $compact =3D 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:
>
>  =E2=80=A2 JIT for real-world web workloads
>
>  =E2=80=A2 Reduce memory allocation in array operations
>
>  =E2=80=A2 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 =3D new WorkerServer();
> $server->onWorkerStart(fn() =3D> loadApp());
> $server->onRequest(fn($req) =3D> handle($req));
> $server->start(4);
> This would:
>
>  =E2=80=A2 Run standalone: `php server.php` =E2=80=93 no nginx, no PHP=
-FPM
>
>  =E2=80=A2 Keep process isolation (each worker is separate)
>
>  =E2=80=A2 Allow resource initialization once per worker
>
>  =E2=80=A2 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 lo=
t of focus on how to make it easy to use right and hard to use wrong.  B=
ecause that is actually a really, really hard problem space.  "Simple wo=
rker 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 t=
he APi) such that it's hard to have things go wrong is itself really har=
d.  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 b=
e done already.  (See also: generics.)

--Larry Garfield