Ich lege meine Karten auf den Tisch: Ich halte True Asyncs Entscheidung, komplett auf colored functions zu verzichten, für die beste Designentscheidung, die je jemand für PHP-Nebenläufigkeit getroffen hat — und ich würde lieber sehen, dass das Projekt PHP 8.6 verpasst, als dass es mit einem aufgeweichten Prinzip landet. Das Projekt — aktuell bei v0.8.4 und ehrlich als experimenteller Core gekennzeichnet — wird auf php.watch mit PHP 8.6 als Ziel geführt, und die Roadmap peilt eine stabile v1.0 im November 2026 an, genau parallel zum 8.6-Release am 19. November. Alpha 1 kam am 2. Juli, Beta 1 ist für Mitte August geplant. Die Uhr tickt also sehr real. Aber die Frage, über die ich streiten will, ist nicht, ob es den Zug erwischt. Sondern ob wir verstehen, worauf wir uns da einlassen.

Zuerst: Warum das farblose Design ausgerechnet für uns so wichtig ist. In JavaScript oder Python gilt: Sobald eine Funktion async ist, muss alles, was sie aufruft, ebenfalls async werden — und die Spaltung kriecht durch deine Codebasis nach oben wie Feuchtigkeit durch eine Wand. True Async sagt: kein Keyword, keine Annotation, kein Rewrite. Du wickelst ganz normalen Code in spawn(), und innerhalb dieser Coroutine werden über 70 Standardfunktionen — file_get_contents, fread, curl_exec, PDO gegen MySQL und PostgreSQL, socket_read, sogar sleep() — stillschweigend non-blocking. Außerhalb einer Coroutine verhalten sie sich exakt wie immer. Für eine Sprache mit fünfundzwanzig Jahren synchroner Libraries auf Packagist ist das kein Komfort-Feature. Es ist der einzige Migrationspfad, der nicht verlangt, das ganze Ökosystem neu zu schreiben.

Und die Technik darunter ist ernsthafter als der übliche Proof of Concept. Connection Pooling für PDO ist eingebaut, damit zwei Coroutinen nicht heimlich denselben Datenbank-Handle zertrampeln. flock(), ein wirklich blockierender Syscall, wird in einen Thread-Pool ausgelagert, sodass der Rest deiner Coroutinen weiterläuft, während eine auf ihren Lock wartet. Es gibt spawn_thread() für echte CPU-Parallelität, und — hier bin ich aufmerksam geworden — einen in C geschriebenen HTTP/1.1-, HTTP/2- und HTTP/3-Server, der direkt im PHP-Prozess läuft, ganz ohne Reverse Proxy davor. Output-Buffer sind pro Coroutine isoliert. Da hat jemand über die langweiligen Fehlermodi nachgedacht — und bei Nebenläufigkeit sind die langweiligen Fehlermodi der eigentliche Job.

Jetzt das ehrliche Gegenargument, denn es ist ein starkes. Colored functions sind nervig, aber sie sind nervig wie ein Feueralarm: Das async-Keyword sagt dir direkt an der Aufrufstelle, dass diese Zeile yielden kann — dass die Welt sich unter dir verändert haben kann, wenn sie zurückkehrt. True Asyncs Transparenz löscht dieses Signal. Eine statische Property, ein memoisiertes Singleton, ein Laravel-Container-Binding, das annimmt, ein Request sei ein isoliertes Universum — all das war sicher, weil PHPs Shared-Nothing-Modell es sicher gemacht hat. Lass denselben Code als kooperative Coroutinen in einem Prozess laufen, und aus diesen Annahmen werden Race Conditions, die du im Diff nicht sehen kannst — denn der Diff besteht aus drei spawn()-Aufrufen und sonst nichts. Genau das, was die Einführung leicht macht, macht die neue Bug-Klasse unsichtbar.

Ich lande trotzdem auf der farblosen Seite, und zwar aus diesem Grund: Die Alternative ist kein sichereres PHP, sondern ein gespaltenes PHP. Dieses Experiment haben wir schon durch. AMPHP, ReactPHP und Swoole sind exzellent, und jedes davon hat ein Paralleluniversum aus Treibern und Clients gebaut, weil die Standardbibliothek nicht mitspielen konnte. Ein colored Core hätte diese Fragmentierung für immer geadelt — ein asynchrones PDO und ein synchrones, ein asynchrones Guzzle und ein synchrones, doppelte Wartung bis ganz nach unten. Transparenz auf Engine-Ebene, wo der Zend-Core, die I/O-Schicht und die Socket-Schicht direkt modifiziert werden, ist die einzige Variante, bei der das Ökosystem konvergiert statt sich zu spalten. Die Concurrency-Bugs sind ein echter Preis. Eine Zweiklassengesellschaft der Libraries ist ein größerer.

Was das praktisch bedeutet: Die Last verschiebt sich von der Syntax zur Disziplin — und zum Tooling. Der Scope-Mechanismus — Structured Concurrency, bei der eine Gruppe von Coroutinen gemeinsam lebt und stirbt, mit einer Cancellation, die keine halb geschriebenen Daten hinterlassen soll — ist die Stelle, auf die ich jetzt jeden Framework-Autor zeigen würde, denn Scopes machen Lebenszyklen wieder sichtbar, wenn die Keywords weg sind. Das Paket true-async/ide-helper (eine --dev-Installation via Composer) liefert PhpStorm, PHPStan und Psalm schon jetzt ordentliche Stubs für spawn() und await(), und ich vermute, dass am Ende statische Analyse den Job übernehmen wird, den anderswo das async-Keyword macht: geteilten veränderlichen Zustand zu markieren, der einen Suspension Point kreuzt. Wenn du selbst herumprobieren willst: Die Extension läuft auf PHP 8.5+ per Installer oder Docker-Image — experimentell, nichts für Production, aber sehr wohl lauffähig.

Also, landet es in 8.6? Das kann niemand versprechen, und ich würde ehrlich lieber einen Zyklus warten, als eine überhastete Core-API zu bekommen, die wir ein Jahrzehnt lang supporten müssen — die verbleibenden Lücken, etwa Verzeichnisoperationen und die PDO-Treiber für Oracle und SQLite, sind die kleine Sorte, aber Core-APIs sind für immer. Meine Frage an dich ist die, die ich selbst immer wieder wälze: Wenn der Request-Lifecycle deines Frameworks anfängt, als Coroutinen in einem einzigen Prozess zu laufen — welche Annahme in deiner eigenen Codebasis bricht als erste? Ich habe für meine eine Shortlist, und kein Eintrag darauf ist schmeichelhaft. Erzähl mir deine.