Rethink PHP's Evolution Direction – Focus on Pragmatism, Not Java-like Complexity

[Qfix]

Description

Summary

PHP has become increasingly complex with features like typed properties, constructor property promotion, attributes, and the upcoming property hooks. While these features have their merits, they steer PHP toward a "Java-like" enterprise language, losing its original simplicity and pragmatic nature. I propose PHP should refocus on what made it great: simplicity, web-native performance, and developer productivity, with a stronger emphasis on concurrency and practical language improvements.

---

Problem Statement

PHP is losing its identity.

Since PHP 7 and especially PHP 8, the language has been adding "enterprise features" that:

• Increase learning curve for new developers
• Make code more verbose without solving real web problems
• Imitate Java without achieving Java's type system completeness
• Neglect the needs of 80% of PHP users (web developers)

Current pain points:

1. Half-hearted type system – It's not truly strong (automatic type juggling still exists), nor truly dynamic. It adds complexity without full benefits.
2. Missing concurrency – PHP still relies on third-party extensions (Swoole, ReactPHP) for async/parallel processing, while Go and Node.js have native solutions.
3. Lack of practical helpers – Basic array operations still require verbose code.
4. Complex features for minority – Attributes, property hooks, and enums are rarely used in typical web development but increase cognitive load.

---

Proposed Solution

Instead of chasing Java, PHP should embrace its identity as the pragmatic web language and focus on:

1. Native Concurrency (Top Priority)

Current:

// Need third-party extensions like Swoole
$server = new Swoole\Http\Server(...);
Proposed:

php
// Native async/await
$results = await([
    http_get('https://api1.com'),
    http_get('https://api2.com'),
    http_get('https://api3.com'),
]);

// Native coroutines
go(function() {
    $data = http_get('https://api.com');
    return process($data);
});
Why: Node.js and Go are eating PHP's market share. Concurrency is the biggest missing piece.

2. Practical Built-in Functions
Current:

php
$names = array_values(array_filter($users, fn($u) => $u->active));
$first = count($names) > 0 ? $names[0] : null;
Proposed:

php
$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); // remove null values
Why: PHP is a web language; array manipulation is 90% of what we do. Make it elegant.

Why This Matters
PHP's competitive advantages:

✅ Simplicity – easy to learn, fast to develop

✅ Web-native – built for HTTP

✅ Deployment – just upload files

✅ Ecosystem – WordPress, Laravel, Composer

What PHP is losing to competitors:

❌ Node.js: better concurrency, async by default

❌ Go: native concurrency, better performance

❌ Python: cleaner syntax, broader ecosystem

PHP should lean into its strengths and fix its weaknesses (concurrency, practicality), not mimic Java.

Conclusion
PHP is at a crossroads. It can:

Continue becoming a "Java-lite" – gaining complexity but never achieving Java's type safety or ecosystem

Lean into its strengths – simple, pragmatic, web-native, and fast

I strongly believe option 2 is the path forward. Please prioritize:

Native async/await/coroutines

Practical array helpers

Simplified syntax (not more complexity)

Let's keep PHP the language that gets things done – not the language that requires an enterprise architect.

Thank you for your time and for maintaining PHP. I'm happy to provide more examples or participate in discussions.

[Qfix]

A Developer's Perspective

I'm a developer who uses both Java and PHP regularly. Here's my honest take:

If PHP continues down the "Java-lite" path, I will simply choose Java for new projects.

Why? Because Java does enterprise features better:

• True strong typing with generics
• Real method overloading
• Mature dependency injection containers
• Complete ecosystem for large-scale applications

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

Every "enterprise feature" added to PHP pushes me closer to Java. Not because Java is better, but because if I need enterprise complexity anyway, I'd rather use a language designed for it from the ground up.

But here's the truth: I don't want to leave PHP.

I want PHP to remain great. I want PHP to get better – better in its own way, not by becoming someone else. I'm speaking up because I care about PHP's future. Because PHP has been good to me, to my career, to the web.

Please keep PHP simple. Keep it pragmatic. Keep it the language that just gets things done. I want PHP to stay great – and I want to keep choosing PHP for years to come.

[Qfix]

A Concrete Proposal

Instead of a full async/await implementation, why not provide a built-in worker management API?

$server = new WorkerServer();
$server->onWorkerStart(fn() => loadApp());
$server->onRequest(fn($req) => handle($req));
$server->start(4);
What this gives developers:

Process isolation – Each worker runs in its own process, just like PHP-FPM. No shared state, no unexpected side effects.

Full control over concurrency – Developers decide how many workers to run, when to start them, and what resources to initialize.

Gradual migration path – Existing PHP-FPM applications can be wrapped with minimal changes. No rewrite required.

No complexity overhead – No need to learn async/await, coroutines, or event loops. Simple, familiar PHP.

Why this matters:

This is the best of both worlds: the simplicity and isolation of PHP-FPM with the flexibility and control of an application server (like Java's Spring Boot or Node.js). Developers get to choose: stay with PHP-FPM for simplicity, or adopt this for more control – and migrate gradually.

It's not about replacing PHP-FPM. It's about giving developers a choice.
php server.php
# The application starts on its own. No nginx, no php-fpm required.

[kallesommernielsen]

Hi @Qfix

This issue belongs to the discussion mailing list at internals@lists.php.net and a likely as an RFC for the features you are proposing. If you are not already on the mailing list, you can sign up here: https://www.php.net/mailing-lists.php. Do be sure you familiarize yourself with the mailing list rules here: https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md

The internals mailing list is where development of PHP takes place where you and put forward your suggestions and how you can involve yourself.

I'm gonna close this issue, unless you intend to use it to raise an RFC,

Good luck,
-K