---
title: "Swooles AOT-Compiler wird zu TypePHP: PHP-Syntax-Code, der zu nativen Binaries kompiliert, Beta bis 1. Oktober"
description: "Am 18. Juni 2026 hat das Swoole-Team seinen Ahead-of-Time-PHP-Compiler offiziell in TypePHP umbenannt, eine eigenständige stark typisierte kompilierte Sprache mit voller PHP-Syntax-Kompatibilität, einer Dual-Engine aus statischer Kompilierung und ZendVM-Laufzeit, nativen Decimal- / BigInt- / BigFloat-Typen, vier stark typisierten C++-gestützten Containern, Uniform Function Call Syntax und direkten C++-ABI-Aufrufen in statische Bibliotheken aus C, C++, Rust und Go. Eine Beta ist bis zum chinesischen Nationalfeiertag (1. Oktober 2026) zugesagt, gefolgt von einer vollständigen Quellcode-Veröffentlichung. Wir entpacken das Dual-Engine-Design, die C++-ABI-Integration, den selbstgehosteten Compiler, was sich gegenüber KPHP, HHVM, PeachPie und FrankenPHP ändert, und die offene Frage, die Roman Pronskiy aufgeworfen hat, wo die Sprache aufhört, PHP zu sein."
date: 2026-06-18
image: "/images/heroes/2026-06-18--typephp-swoole-aot-native-binary-php.png"
author: lschvn
tags: ["runtimes", "tooling"]
tldr:
  - "Der Ahead-of-Time-PHP-Compiler des Swoole-Teams wurde in TypePHP umbenannt und wird als eigenständige stark typisierte kompilierte Sprache ausgeliefert, nicht als schnelleres PHP. Die Beta ist vor dem chinesischen Nationalfeiertag am 1. Oktober 2026 zugesagt, gefolgt von einer vollständigen Quellcode-Veröffentlichung auf GitHub unter swoole/aot-compiler. Das offizielle Swoole-WeChat-Konto hat die Ankündigung am 18. Juni 2026 veröffentlicht, und Roman Pronskiy, Leiter von PhpStorm bei JetBrains, markierte die Umbenennung in einem X-Artikel in derselben Woche."
  - "Das herausragende Designmerkmal von TypePHP ist die Dual-Engine: Das Hauptprogramm wird zu nativem Maschinencode kompiliert, aber die ZendVM-Laufzeit bleibt innerhalb des Binärs erhalten, sodass die kompilierte ausführbare Datei zur Laufzeit gewöhnliche `.php`-Skripte über `require`/`include` laden kann. Dadurch bleiben die gesamte PHP-Erweiterungsfläche (curl, mysqli, PDO, Swoole und selbst geschriebene C/C++-Erweiterungen) und das Composer-Autoloading unverändert funktionsfähig. Die Performance wird als zehn- bis hundertfach schneller als interpretiertes PHP angegeben, und das erzeugte Binary kann nicht zu PHP-Quellcode dekompiliert werden."
  - "Drei neue Sprachmerkmale kommen über PHP hinaus: native BigInt-, BigFloat- und Decimal-Typen für exakte wissenschaftliche und finanzmathematische Berechnungen (sodass `0.1 + 0.2` exakt `0.3` ergibt); vier stark typisierte Container (`std::array`, `std::vector`, `std::map`, `std::unordered_map`), die das universelle `array` ersetzen; und die Uniform Function Call Syntax, mit der jede Funktion als Methode auf jedem Wert aufgerufen werden kann, einschließlich eingebauter Integer und Strings, und mit der Erweiterungsmethoden zu bestehenden Typen hinzugefügt werden können. Der Compiler selbst wird in TypePHP selbst geschrieben, nach der Tradition, dass der Go-Compiler in Go geschrieben ist."
faq:
  - question: "Was ist TypePHP?"
    answer: "TypePHP ist der neue Name des Ahead-of-Time-PHP-Compilers des Swoole-Teams. Er wird als eigenständige stark typisierte kompilierte Sprache ausgeliefert, deren Syntax mit PHP kompatibel bleibt, deren Laufzeit aber nativer Maschinencode plus eingebettete ZendVM ist. Das Swoole-Team kündigte die Umbenennung am 18. Juni 2026 auf dem offiziellen Swoole-WeChat-Konto an, und das GitHub-Repository befindet sich unter swoole/aot-compiler. Eine Beta-Binary ist bis zum chinesischen Nationalfeiertag (1. Oktober 2026) zugesagt, und die vollständige Quellcode-Veröffentlichung ist für danach geplant. Der frühere Produktname Swoole AOT wird eingestellt."
  - question: "Wie unterscheidet sich TypePHP von einem schnelleren PHP?"
    answer: "TypePHP positioniert sich nicht als schnelleres PHP. Es ist eine eigenständige kompilierte Sprache, die PHP-Syntax verwendet und die ZendVM als Laufzeitkomponente mitliefert, nicht als primäres Ausführungsmodell. Das Hauptprogramm wird zu nativem Maschinencode kompiliert, und das kompilierte Binary kann zusätzlich gewöhnliche `.php`-Skripte zur Laufzeit über `require` und `include` laden, wodurch die PHP-Erweiterungsfläche, das Composer-Autoloading und bestehende C/C++-Erweiterungen funktionsfähig bleiben. Pronskiy formuliert es in seinem X-Artikel unverblümt: Je weiter TypePHP geht, desto weniger ist es PHP, was dieselbe Entwicklung ist, die Facebook von HipHop zu Hack zu HHVM durchlaufen hat."
  - question: "Läuft mein bestehender PHP-Code auf TypePHP?"
    answer: "Ja, insofern TypePHP die volle PHP-Syntax-Kompatibilität bewahrt und die ZendVM als Fallback-Laufzeit mitliefert. Die kompilierte ausführbare Datei kann zur Laufzeit gewöhnliche `.php`-Dateien per `require` oder `include` einbinden und sie durch die eingebettete Zend interpretieren, sodass dasselbe Composer-Autoloading, derselbe Erweiterungsstack und derselbe C/C++-Erweiterungscode, der unter PHP 8.x läuft, unverändert in einer TypePHP-Binary laufen sollte. Die Behauptung des Swoole-Teams ist 100% PHP-Ökosystem-Kompatibilität, einschließlich Drittanbieter-Composer-Paketen und selbst geschriebener C/C++-Erweiterungen. Der Haken ist, dass Sprachmerkmale, die es in PHP nicht gibt (BigInt, typisierte Container, UFCS), nur in Code funktionieren, der auf den TypePHP-Compiler abzielt."
  - question: "Wie unterscheidet sich TypePHP von KPHP, HHVM, PeachPie oder FrankenPHP?"
    answer: "KPHP (VK, GPL-3.0, 1.500+ Sterne) ist der engste Vorläufer: Es kompiliert einen PHP-Dialekt nach C++ und liefert native Binaries aus, embeddet aber nicht die Zend-Laufzeit, sodass unveränderte `.php`-Dateien nicht zur Laufzeit geladen werden können. HHVM (Meta) begann als schnelleres PHP und driftete in Hack ab, eine eigenständige Sprache, was das abschreckende Beispiel ist, das Pronskiy zitiert. PeachPie kompiliert PHP nach .NET, mit einem anderen Laufzeitmodell. FrankenPHP (11.000+ Sterne, MIT) ist ein moderner PHP-Application-Server, der in Go geschrieben ist und ein Standalone-Binary ausliefern kann, aber den PHP-Interpreter einbettet, kein kompiliertes Artefakt. Das Unterscheidungsmerkmal von TypePHP ist die Dual-Engine: statisch kompilierter Maschinencode plus eingebettete Zend, die unverändertes PHP on-the-fly interpretieren kann, mit C++-ABI-Zugriff als erstklassiger Funktion."
  - question: "Kann ich aus TypePHP C-, C++-, Rust- oder Go-Code aufrufen?"
    answer: "Ja. TypePHP baut direkt auf der C++-ABI auf, und ein TypePHP-Programm kann in `.a`/`.lib`-Statikbibliotheken und `.so`/`.dll`-Dynamic Libraries hineinrufen, die von C, C++, Rust und Go erzeugt wurden, ohne eine PHP-Erweiterung zu schreiben. Die Referenzbeispiele im swoole/aot-compiler-Repository liefern eine JNI-Brücke, die Java über `jni.h` und `libjvm.so` (Java 25) aufruft, ein Tetris-Spiel, dessen Grafikschicht in C++ gegen SDL implementiert ist, und ein Windows-GUI-Hello-World. Der Mechanismus ist ein Stub-Datei-Pattern: Eine C++-Klasse erbt von `Box`, ein PHP-seitiger Stub deklariert die C++-Funktionen, und der Compiler verdrahtet den Aufruf zur Kompilierzeit."
  - question: "Was sind die drei neuen Sprachmerkmale in TypePHP?"
    answer: "Erstens native BigInt-, BigFloat- und Decimal-Typen für exakte Arithmetik. Mit `use decimal_types;` gibt `0.1 + 0.2` `0.3` aus statt des IEEE-754-Werts `0.30000000000000004`, den Sie in PHP erhalten. Mit `use bigint_types;` ergibt `2 ** 80` `1208925819614629174706176`, statt in einen Float überzulaufen. Zweitens vier stark typisierte Container: `std::array(type, size)`, `std::vector(type, [size])`, `std::map(ktype, vtype)` und `std::unordered_map(ktype, vtype)`, die das universelle `array` von PHP durch C++-gestützte typisierte Strukturen ersetzen. Drittens die Uniform Function Call Syntax, die es jedem Wert erlaubt, einen Methodenaufruf gegen jede Funktion zu erhalten (`$a = 2; $a->pow(80)->toString()->length();`), und mit der Benutzercode Erweiterungsmethoden auf eingebauten Typen registrieren kann."
  - question: "Ist TypePHP tatsächlich schon Open Source?"
    answer: "Noch nicht. Stand 18. Juni 2026 enthält das swoole/aot-compiler-Repository auf GitHub nur ein README und Beispielprojekte, und die Release-Seite hostet Closed-Source-Testbinaries für Windows x86_64, Linux x86_64 und macOS arm64, aktuell bei v0.2.3. Das Swoole-Team hat sich verpflichtet, den Compiler-Quellcode nach der Beta am 1. Oktober 2026 hochzuladen. Pronskiys X-Artikel markiert die offene Frage: Der bestehende Swoole Compiler 3.2 ist ein kommerzielles Produkt, das über business.swoole.com verkauft wird, und eine MIT-artige Open-Source-Veröffentlichung für die AOT-Linie ist nicht bestätigt."
  - question: "Was bedeutet „selbstgehosteter Compiler" für TypePHP?"
    answer: "Es bedeutet, dass der TypePHP-Compiler in TypePHP selbst geschrieben wird, in derselben Tradition, in der der Go-Compiler in Go geschrieben ist. Der erste Alpha-TypePHP-Compiler wurde mittels Zend-PHP kompiliert, dann verwendet, um sich selbst zu kompilieren, und das Swoole-Team berichtet, dass in der aktuellen v0.2.3 sowohl das selbstgehostet kompilierte Binary als auch das Zend-PHP-kompilierte Binary die gesamte Unit-Test-Suite bestehen. Selbsthosting ist nicht nur ein stilistischer Punkt: Es ist ein Stresstest für die neuen Sprachmerkmale, weil der Compiler die typisierten Container, BigInt-Arithmetik, UFCS und C++-ABI-Aufrufe in Produktionscode exerziert, nicht in Spielzeugbeispielen."
---

Am Morgen des 18. Juni 2026 (Pekinger Zeit) veröffentlichte das offizielle WeChat-Konto des Swoole-Teams eine bildschirmfüllende Ankündigung: Das Swoole-AOT-Compiler-Projekt wurde formell in **TypePHP** umbenannt, eine Beta-Binary ist vor dem chinesischen Nationalfeiertag am 1. Oktober 2026 zugesagt, und der vollständige Quellcode wird danach auf GitHub hochgeladen. In derselben Woche veröffentlichte Roman Pronskiy, Leiter von PhpStorm bei JetBrains und Vorstandsmitglied der PHP Foundation, einen X-Artikel mit dem Titel *„Swoole AOT is officially becoming TypePHP"*, in dem er beobachtet, dass das Team nun unverblümt ausspricht, was es zuvor nur angedeutet hatte: Dies ist eine eigenständige, stark typisierte kompilierte Sprache, kein schnellerer PHP-Interpreter. Beide Quellen stimmen in den Schlagzeilenzahlen überein. Die interessanten Fragen liegen alle im Mechanismus, und es gibt mehr Mechanismus, als der WeChat-Post oder der X-Artikel fassen können.

Die beiden Quelldokumente ergeben zusammen gelesen ein klareres Bild als jedes für sich allein. Der WeChat-Post ist die offizielle Ankündigung und trägt die technischen Behauptungen im Framing des Teams. Pronskiys Artikel ist die Lesart von außen, geschrieben von der Person, die die IDE leitet, die die meisten PHP-Entwickler verwenden, und enthält die Framing-Korrektur, die der Rest der Branche zuerst hören wird: TypePHP bewegt sich auf derselben Bahn, die Facebook von HipHop zu Hack zu HHVM geführt hat, und die Frage, die es sich im Oktober zu stellen lohnt, ist nicht, ob das Binary schneller läuft als PHP, sondern ob die Sprache überhaupt noch PHP ist.

Vor dem tieferen Einstieg die Framing-Korrektur, die es sich zu nennen lohnt: TypePHP ist kein neues JIT für die Zend-Engine, und es ist kein Nachfolger der Swoole-Laufzeit. Swoole im engeren Sinne ist die asynchrone, Coroutine-basierte PHP-Erweiterung, die seit dem letzten Jahrzehnt die De-facto-Hochleistungslaufzeit für PHP in China ist, und sie lebt unter swoole/swoole-src (18.890 Sterne, letzter Push am 8. Juni 2026). TypePHP stammt aus einer anderen Produktlinie innerhalb desselben Unternehmens, dem Swoole Compiler, der seit der 3.x-Linie kommerziell als Werkzeug zur PHP-Opcode-Verschlüsselung und -Verschleierung verkauft wird. Version 4.0 dieses Compilers ist diejenige, die umbenannt wird. Der Compiler baut auf `swoole/phpx`, dem C++-Wrapper des Teams für die Zend-Engine-API (856 Sterne, Apache-2.0, letzter Push am 17. Juni 2026), also derselben Bibliothek, die die C++/PHP-Erweiterungsarbeit des Unternehmens seit Jahren speist. Die Umbenennung ist keine Runtime-Geschichte; es ist eine Compiler-Geschichte, die zufällig eine Runtime als Kompatibilitätsschicht mitliefert.

## Das Dual-Engine-Design

Die folgenreichste Architekturentscheidung in TypePHP ist, dass die ZendVM nicht entfernt wird. Sie wird innerhalb des kompilierten Binärs als Fallback-Laufzeit mitgeliefert. Die WeChat-Ankündigung sagt das direkt: Das Hauptprogramm wird statisch zu nativen Maschineninstruktionen kompiliert, aber die ausführbare Datei kann weiterhin `require` und `include` aufrufen, um zur Laufzeit gewöhnliche `.php`-Skripte zu laden, und diese Skripte werden durch die eingebettete Zend interpretiert. Das Swoole-Team nennt dies „Dual-Engine", und die unmittelbare Konsequenz ist volle PHP-Ökosystem-Kompatibilität. Composer-Autoloading funktioniert, die Erweiterungen curl, mysqli und PDO funktionieren, die Swoole-Erweiterung funktioniert, und jede selbst geschriebene C/C++-Erweiterung, die gegen PHP 8.x läuft, läuft unverändert innerhalb der TypePHP-Binary.

Dies ist die Designentscheidung, die TypePHP von jedem früheren PHP-zu-nativ-Compiler unterscheidet. KPHP, das VK-Projekt, das der engste Analogon ist, kompiliert einen PHP-Dialekt nach C++ und erzeugt native Binaries, embeddet aber nicht die Zend-Laufzeit, sodass unveränderte `.php`-Dateien nicht zur Laufzeit geladen werden können und die Erweiterungsfläche eine kuratierte Teilmenge ist. TypePHP bewahrt die gesamte Erweiterungsfläche, weil es nicht versucht, Zend zu entfernen. Das kompilierte Binary verwendet einfach nativen Code für den heißen Pfad und fällt auf Interpretation zurück, wenn es eine Datei sieht, die es nicht kompiliert hat. Das Swoole-Team arbeitet seit Jahren unter der AOT-Marke an dieser Dual-Engine-Architektur, und die Umbenennung in TypePHP ist teilweise eine Anerkennung dessen, dass dies nun die definierende Eigenschaft des Projekts ist, kein vorübergehendes Implementierungsdetail.

Die Performance-Behauptung, zehn- bis hundertfach schneller als PHP, bezieht sich auf den kompilierten Teil des Programms. Da die kompilierte Ausgabe native Maschineninstruktionen ohne Interpreter in der Schleife ist, wird der typspezialisierte, inline-fähige, branch-predicted Pfad einer engen Schleife so schnell sein wie der entsprechende C++-Code. Der interpretierte Teil, wenn das Programm zur Laufzeit ein `.php`-Skript lädt, läuft mit Standard-PHP-Geschwindigkeit, aber das Swoole-Team argumentiert, dass der Großteil der Arbeit in einer typischen Anwendung im Voraus kompiliert werden kann, wobei die dynamischen Teile der kleinen Oberfläche vorbehalten bleiben, die wirklich dynamisch sein muss (Plugin-Laden, Konfigurationsskripte, Drittanbieter-Composer-Pakete, die nicht rekompiliert wurden). Für eine vollständig rekompilierte Anwendung ist die Dual-Engine unsichtbar. Für eine teilweise kompilierte Anwendung, die weiterhin dynamische Plugins lädt, ist die Engine ein Sicherheitsnetz, keine Regression.

Es gibt eine verwandte Behauptung, die es wert ist, für sich genommen ernst genommen zu werden: Das kompilierte Binary kann nicht zu PHP-Quellcode dekompiliert werden. Der WeChat-Post sagt dies explizit als Feature, eingeordnet in den kommerziellen Softwarevertrieb. Die Sichtbarkeit von PHP-Quellcode war schon immer ein Reibungspunkt für Anbieter, die Closed-Source-Anwendungen verteilen wollen, und der bestehende Swoole Compiler 3.2 verkauft genau aus diesem Grund Opcode-Verschlüsselung und Control-Flow-Verschleierung. TypePHP verschlüsselt keine Opcodes; es erzeugt Maschinencode, der intrinsisch schwieriger zu rekonstruieren ist als Bytecode. Das kommerzielle IP-Framing des Projekts ist keine Randnotiz; es ist einer der zwei oder drei Gründe, warum das Swoole-Team seit Jahren in die Compiler-Linie investiert.

## Die drei neuen Sprachmerkmale

TypePHP wird als PHP-Syntax-kompatibel beschrieben, aber die Sprache ist keine strikte Teilmenge von PHP. Das Swoole-Team hat drei Funktionsbereiche hinzugefügt, die es in PHP 8.x nicht gibt, und jeder davon ist eine echte ergonomische oder Performance-Veränderung für Code, der gegen TypePHP geschrieben wird, keine Marketing-Zeile.

Das erste Merkmal ist native exakte Arithmetik. PHP-Floats sind IEEE-754-Doubles, und das kanonische Beispiel für den Präzisionsverlust ist `0.1 + 0.2`, das zu `0.30000000000000004` auswertet. In TypePHP macht das Importieren von `decimal_types` das Standard-Float-Literal zu einem `Decimal` statt eines `float`, und `0.1 + 0.2` gibt exakt `0.3` aus. Das Importieren von `bigint_types` macht das Analoge für Integer-Literale, sodass `2 ** 80` zu `1208925819614629174706176` auswertet, statt in einen Float überzulaufen, wie es in PHP der Fall wäre. Der BigFloat-Typ ist das dritte Mitglied derselben Familie. Der WeChat-Post stellt diese als die Antwort auf wissenschaftliche und finanzmathematische Anwendungsfälle vor, in denen Fließkommafehler inakzeptabel sind; die praktische Implementierung scheint ein konfigurierbarer Literal-Level-Switch zu sein, nicht ein pauschaler Ersatz des Float-Typs, was die Tür für Code offen hält, der den IEEE-754-Pfad wirklich braucht.

```php
use decimal_types;

function main() {
    $v1 = 0.1;
    $v2 = 0.2;
    // TypePHP: 0.3. PHP: 0.30000000000000004.
    echo $v1 + $v2;
}
```

Das zweite Merkmal sind vier stark typisierte Container. Das `array` von PHP ist universell: Es ist sowohl eine Liste als auch eine Map, Schlüssel und Werte sind untypisiert, und dieselbe Struktur muss jeden Collection-Anwendungsfall bedienen. TypePHP ersetzt dies durch `std::array(type, size)` für Arrays fester Größe, `std::vector(type, [size])` für dynamische Arrays, `std::map(ktype, vtype)` für geordnete Maps, gestützt auf einen Rot-Schwarz-Baum, und `std::unordered_map(ktype, vtype)` für unsortierte Hash-Maps. Die Namen und die zugrundeliegenden Implementierungen sind direkte Aufrufe in die C++-Standardbibliothek, was dieselbe Strategie ist, die Phlex und andere System-Sprachprojekte verwendet haben, um deterministische Performance und vorhersehbares Speicherlayout zu erhalten. Die Container der C++-Standardbibliothek sind auch der Grund, warum das Swoole-Team einen selbstgehosteten Compiler ausliefern kann: Die typisierten Container sind keine benutzerdefinierte Datenstruktur mit einem benutzerdefinierten Speichermodell, sie sind eine dünne Schicht über `std::vector` und Freunden, und der Compiler ist klein genug, um in TypePHP selbst geschrieben zu werden.

```php
// Schlüssel: string. Wert: stdClass.
$map = std::map(complex_types::type_string, stdClass::class);
$map["key"] = new stdClass;
$map["key"]->data = "hello";
```

Das dritte Merkmal ist die Uniform Function Call Syntax, abgekürzt UFCS, plus Erweiterungsmethoden. Das WeChat-Beispiel ist der sauberste Weg, die Idee zu sehen. Mit UFCS kann jeder Wert einen Methodenaufruf gegen jede Funktion erhalten:

```php
$a = 2;
// 2^80, zu String, dann Länge dieses Strings.
echo $a->pow(80)->toString()->length();

$b = "hello world!";
// Splitten, dann prüfen, ob die resultierende Liste "world" enthält.
$b->split(' ')->contains("world");
```

In Standard-PHP gibt der Aufruf `pow(2, 80)` einen int zurück (oder einen float bei Überlauf), `toString()` ist keine Methode, und `length()` ist keine Methode auf einem String. In TypePHP löst der Compiler `$a->pow(80)` zu `pow($a, 80)` auf, `$a->pow(80)->toString()` zu `toString(pow($a, 80))`, und so weiter, wobei die Aufrufe verkettet werden. Dies ist ein Merkmal, das in D, Nim und (mit Einschränkungen) Rust existiert, und der praktische Effekt ist, dass das Hinzufügen neuer Methoden zu bestehenden Typen keine Erweiterung der Standardbibliothek erfordert, weil jede benutzerdefinierte Funktion als Methode aufgerufen werden kann. Das Begleitmerkmal, Erweiterungsmethoden, erlaubt es dem Benutzer, `function int_to_bytes(int $num): string` zu deklarieren und dann `$value->toBytes()` auf einem Integer aufzurufen, wobei der Compiler bei Typübereinstimmung an die Erweiterungsmethode dispatcht. Der WeChat-Post enthält das ausgearbeitete Beispiel:

```php
function int_to_bytes(int $num): string {
    return ($num / 1024) . 'Kb';
}

$value = 92160;
// Compiler matcht int_to_bytes, gibt "90Kb" aus.
echo $value->toBytes();

var_dump($value->toBytes()->equals('90Kb'));
```

Die drei Merkmale zusammen sind das Sprachdesign, das TypePHP weniger wie einen PHP-Dialekt und mehr wie eine kleine stark typisierte Sprache wirken lässt, die zufällig die Oberflächensyntax von PHP teilt. Das ist auch die Frage, die Pronskiy aufwirft, und es ist diejenige, die den Diskurs um das Projekt im Oktober dominieren wird.

## Die C++-ABI als erstklassiges Feature

Die Entscheidung, den Compiler auf der C++-ABI aufzubauen, statt auf einem PHP-Erweiterungsmodell, ist die zweite Architekturentscheidung, die ändert, was für eine Art von Projekt TypePHP ist. Der WeChat-Post legt den Punkt direkt dar: Ein TypePHP-Programm muss nicht in eine C/C++-Erweiterung eingewickelt werden, um nativen Code aufzurufen. Es kann gegen `.a`- und `.lib`-Statikbibliotheken linken und `.so`- und `.dll`-Dynamic Libraries laden, die von C, C++, Rust und Go erzeugt wurden, ohne Glue-Code jenseits einer Stub-Deklaration. Der Compiler verdrahtet den Aufruf zur Kompilierzeit, und das resultierende Binary ruft den nativen Code über die C++-Standardaufrufkonvention auf.

Die Referenzbeispiele im `swoole/aot-compiler`-Repository zeigen, wie das in der Praxis aussieht. Das Verzeichnis `examples/jni` enthält eine vollständige JNI-Brücke: Die C++-Seite inkludiert `<jni.h>` und `<phpx.h>`, linkt gegen `-ljvm` und exponiert einen kleinen Satz von Funktionen `jni_init`, `jni_find_class`, `jni_new_object`, `jni_call`, `jni_get`, `jni_set` an die PHP-Seite. Die PHP-Seite instanziiert ein Java-`Hello`-Objekt, ruft eine `greet`-Methode darauf auf, liest und schreibt die Felder `name` und `age` über die JNI-Reflection-API und gibt die Ergebnisse aus. Die `project.yml` für das Beispiel listet die JDK-25-Includepfade und das `-Wl,-rpath`-Flag, das auf die JVM-Shared-Library zeigt. Das Beispiel kompiliert und läuft gegen eine unveränderte OpenJDK-Installation.

Das Verzeichnis `examples/tetris-sdl` geht weiter. Die Spiellogik (Brettzustand, Piece-Rotation, Linienräumung, Punktewertung, Spielende-Erkennung) ist in TypePHP implementiert, und die SDL-Grafikaufrufe sind in C++ gegen die Quelldatei `cpp-src/tetris.cc` implementiert. Die C++-Seite definiert eine `TetrisBox`-Klasse, die von `Box` erbt (die C++-Basisklasse in `phpx` für Objekte, die PHP exponiert werden), und die PHP-Seite hält eine `mixed $game`-Referenz, die auf eine `TetrisBox`-Instanz zeigt. Die C++-Schicht verwaltet das SDL-Fenster, die Renderingschleife, die Tastatureingabeverarbeitung und das UTF-8-Rendering für die chinesischsprachige Dokumentation. Eine `tetris.stub.php`-Datei deklariert die C++-Funktionen und Typen, damit der TypePHP-Compiler die Aufrufe auflösen kann. Das Verzeichnis `examples/win32-hello` macht das Äquivalent für die Win32-API: ein Console-Hello-World, ein GUI-Hello-World mit Fensterklasse und Message-Loop, und eine dritte Variante, die die Windows-Konfigurationsschicht des Projekts demonstriert. Das Verzeichnis `examples/tetris-win32` ist der Windows-native Port des SDL-Tetris-Beispiels.

Das Muster ist in allen vier Fällen dasselbe. Die C++-Seite implementiert den plattformspezifischen oder performance-kritischen Code, die TypePHP-Seite implementiert die Anwendungslogik, und die Stub-Datei ist der Vertrag zwischen den beiden. Es ist keine PHP-Erweiterung involviert. Der Kompilierschritt ist `php bin/compiler.php build examples/tetris-sdl` (oder das Äquivalent gegen das `bin/compiler.php`, das mit der Closed-Source-Binary ausgeliefert wird), und die Ausgabe ist ein Windows-`.exe`, das doppelgeklickt werden kann. Dies ist dasselbe Architekturmuster, das Flutter verwendet, um Plattform-APIs zu exponieren, und dasselbe Muster, das es einer Rust-Anwendung erlaubt, eine C-Bibliothek über `extern "C"` aufzurufen. Die Neuheit besteht darin, es aus PHP-Syntax-Quellcode zu tun, mit der PHP-seitigen Aufrufkonvention, die vom Compiler aufgelöst wird, und mit der Zend-Laufzeit, die neben dem kompilierten Code als Fallback ausgeliefert wird.

Die phpx-Bibliothek, die dies ermöglicht, ist es wert, für sich genommen gekannt zu werden. `swoole/phpx` ist ein C++-Wrapper für die Zend-Engine-API, der seit 2017 im Swoole-Ökosystem präsent ist (er geht dem AOT-Compiler um Jahre voraus), und er ist es, was die C++-Integration ergonomisch macht. Ohne phpx müsste der C++-Code, der eine Klasse an PHP exponiert, das Zend-Referenzzählen, die Typkoerzion und den Call-Stack-Tanz manuell verwalten, was genau die Reibung ist, die die PHP-Erweiterungsentwicklung historisch zu einer Spezialistenaktivität gemacht hat. Mit phpx liest sich der C++-Code wie normales C++, das zufällig mit PHP-Stil-Objekten interagiert. Die `Box`-Klasse des AOT-Compilers ist eine phpx-Primitive, und die Zeile `using namespace php;` im JNI-Beispiel ist es, die die C++-Seite sich wie ein Peer der PHP-Seite anfühlen lässt. Dieselbe Bibliothek ist es, auf der die bestehende Swoole-Erweiterung aufbaut, und der AOT-Compiler ist die natürliche Erweiterung der Investition des Teams in C++/PHP-Interoperabilität.

## Wie TypePHP im Vergleich zu KPHP, HHVM, PeachPie, FrankenPHP und RoadRunner abschneidet

Das PHP-Ökosystem hat ein halbes Dutzend ernsthafter Versuche gesehen, die Sprache schneller zu machen, und TypePHP ist der jüngste. Jedes der früheren Projekte hat einen anderen Kompromiss gemacht, und der Kompromiss, den TypePHP macht, ist der ehrgeizigste und riskanteste.

**KPHP** ([VKCOM/kphp](https://github.com/VKCOM/kphp), 1.515 Sterne, GPL-3.0, letzter Push am 18. Juni 2026) ist der engste Vorläufer. KPHP kompiliert einen PHP-Dialekt nach C++ und führt das C++ dann durch einen System-Compiler, um ein natives Binary zu erzeugen. Das resultierende Programm ist dramatisch schneller als interpretiertes PHP, und das Projekt ist seit Jahren in VK-Größenordnung produktionsreif. Der Kompromiss, den KPHP macht, ist derselbe, den jeder PHP-zu-C++-Compiler macht: Es embeddet nicht die Zend-Laufzeit, es unterstützt nicht die volle PHP-Erweiterungsfläche, und der Dialekt ist eine strikte Teilmenge von PHP mit Typisierungsannotationen. Code, der auf KPHP läuft, ist ein KPHP-Programm, und Code, der es nicht ist, ist nicht portabel. KPHP's GitHub wird aktiv gepflegt, und das Projekt bleibt der stärkste Beweis dafür, dass ein kompiliertes PHP im großen Maßstab technisch machbar ist. Das Unterscheidungsmerkmal von TypePHP gegenüber KPHP ist die Dual-Engine und die C++-ABI-Integration, beides hat KPHP explizit nicht.

**HHVM** ([facebook/hhvm](https://github.com/facebook/hhvm), 18.632 Sterne, NOASSERTION-Lizenz, letzter Push am 18. Juni 2026) ist das abschreckende Beispiel, das Pronskiy heraufbeschwört. HHVM begann als HipHop-Compiler, ein internes Facebook-Projekt, um PHP schneller zu machen, und endete als Laufzeit für Hack, eine eigenständige Sprache, die die PHP-Syntax auf inkompatible Weise forkte. Die PHP-Community hat ein Jahrzehnt damit verbracht zu debattieren, ob Hack noch PHP sei, und die praktische Antwort ist nein: Das Typsystem, die Standardbibliothek und die Spracherweiterungen sind alle separat. Das HHVM-Projekt wird weiterhin gepflegt, aber sein primärer Anwendungsfall ist es nun, bestehenden Hack-Code bei Meta auszuführen, nicht PHP-Code aus der breiteren Community. Pronskiys Punkt ist, dass die Entwicklung von „schnellem PHP" zu „eigenständiger Sprache" ein ausgetretener Pfad ist, und TypePHP befindet sich auf dem frühen Teil dieses Pfads. Die Umbenennung von „Swoole AOT" zu „TypePHP" ist, in seiner Lesart, der Moment, in dem das Projekt sich zum Language-Fork bekennt.

**PeachPie** ([peachpiecompiler/peachpie](https://github.com/peachpiecompiler/peachpie), 2.480 Sterne, Apache-2.0, letzter Push am 9. Juni 2026) kompiliert PHP nach .NET, mit der auf CoreCLR gehosteten Laufzeit. Der Vorteil ist der volle Zugang zum .NET-Ökosystem, der Nachteil ist dasselbe Dialekt-Problem wie bei KPHP, plus eine Laufzeitabhängigkeit von .NET. PeachPie ist die stärkste Option für Organisationen, die bereits .NET-Shops sind und PHP-Bibliotheken konsumieren wollen, aber es ist kein Kandidat für allgemeine PHP-Beschleunigung. TypePHP und PeachPie sind keine direkten Konkurrenten; sie zielen auf unterschiedliche Deployment-Stacks.

**FrankenPHP** ([php/frankenphp](https://github.com/php/frankenphp), 11.156 Sterne, MIT, letzter Push am 15. Juni 2026) ist der moderne PHP-Application-Server, geschrieben in Go auf Basis von Caddy. FrankenPHP embeddet den PHP-Interpreter, unterstützt das Early-Hints-HTTP-Feature und kann als Standalone-Binary paketiert werden, das PHP und die Anwendung zusammen enthält. Die Performance-Gewinne gegenüber PHP-FPM sind substanziell, und die Operationsgeschichte ist viel einfacher als PHP hinter nginx zu betreiben. FrankenPHP ist kein Compiler; es ist ein Server. Der Vergleich mit TypePHP ist „schnellere Laufzeit" versus „kompiliertes Binary", und die beiden lösen unterschiedliche Probleme. FrankenPHP greifen Sie, wenn Sie bestehende PHP-Anwendungen schneller deployen wollen; zu TypePHP greifen Sie, wenn Sie neuen Code in einer stark typisierten Sprache schreiben wollen, die wie PHP aussieht.

**RoadRunner** ([roadrunner-server/roadrunner](https://github.com/roadrunner-server/roadrunner), 8.472 Sterne, MIT, letzter Push am 17. Juni 2026) ist ein PHP-Application-Server und Prozessmanager, geschrieben in Go. RoadRunner behält PHP-FPM als Worker-Prozess, ersetzt aber den Frontend-Webserver durch ein Go-Binary, das Requests, statische Dateien und WebSockets nativ behandelt. Die Architektur ist hybrid: PHP wird interpretiert, Go wird kompiliert, und die Grenze ist klar definiert. RoadRunner ist der nächste Analogon im Geist zur Dual-Engine von TypePHP, mit dem Unterschied, dass die Grenze bei RoadRunner zwischen zwei Prozessen liegt, nicht zwischen zwei Ausführungsmodellen innerhalb desselben Binärs.

Die Unterscheidungsmerkmale, die TypePHP von allen diesen abheben: die Dual-Engine, die C++-ABI als erstklassiges Feature, die typisierten Container, die BigInt/BigFloat/Decimal-Typen, UFCS und der selbstgehostete Compiler. Die Dual-Engine ist die einzige, die eine eingebettete Zend-Laufzeit erfordert, und die C++-ABI-Integration ist die einzige, die native Interop als primäre Fähigkeit behandelt, nicht als Erweiterungs-API. Die anderen Merkmale (Decimal, typisierte Container, UFCS) sind unabhängig von der PHP-Syntax-Frage und wären in jeder Sprache wertvoll. Die Frage, die TypePHP im Oktober beantworten muss, ist, ob die Sprachmerkmale der Punkt sind oder ob die PHP-Syntax der Punkt ist. Die aktuelle Ankündigung legt nahe, dass die Sprachmerkmale der Punkt sind und die PHP-Syntax die Oberfläche, was das Projekt auf die Language-Fork-Seite von Pronskiys Dichotomie stellt.

## Der Release-Status Mitte Juni 2026

Zum Zeitpunkt der Ankündigung befindet sich TypePHP in einem Pre-Beta-Zustand. Das `swoole/aot-compiler`-Repository auf GitHub wurde am 11. Mai 2026 erstellt, die v0.1.0-Release wurde am selben Tag mit einer Windows-x86_64-Binary (43 MB), einer Linux-x86_64-Binary (726 KB) und einer macOS-arm64-Binary (1,6 MB) ausgeliefert. Die v0.2.3-Release am 15. Juni 2026 lieferte aktualisierte Windows- (52 MB) und Linux- (2 MB) Binaries aus. Die Release-Assets sind Closed-Source-vorgebaute Binaries; das Repository selbst enthält nur das README und die Beispielprojekte. Das README beschreibt das Projekt als die kommerzielle Swoole-Compiler-Produktlinie: Version 3.2, das bestehende kommerzielle Produkt, „verschlüsselt und verschleiert PHP-Opcode-Bytecode, unter Verwendung von Control-Flow-Verschleierung, Junk-Instruktionen, Variablen-Verschleierung, Funktionsnamen-Verschleierung, VM-Schutz, Code-Flattening, SCCP-Optimierung und anderen Techniken, um PHP-Quellcode in verschlüsselten binären Bytecode zu kompilieren". Version 4.0 ist der neue AOT-Compiler, beschrieben als „kompiliert PHP-Code direkt in Binärinstruktionen und erzeugt native ausführbare Dateien oder Dynamic Libraries für Plattformen wie Windows, Linux und macOS". Der Dokumentationslink im README zeigt auf `doc.swoole.com/@aot-compiler/`, was zum Zeitpunkt des Schreibens einen 404 zurückgibt (die Seite liefert „知识管理 404 文档不存在或已被删除", eine chinesischsprachige 404-Seite), was darauf hindeutet, dass die Dokumentation parallel zur Umbenennung migriert wird.

Die Binaries v0.1.0 und v0.2.3 sind die „Testversionen", zu deren Download der WeChat-Post einlädt. Die Behauptung des Swoole-Teams ist, dass in v0.2.3 sowohl der selbstgehostet kompilierte Compiler als auch der Zend-PHP-kompilierte Compiler die gesamte Unit-Test-Suite bestehen, was der Meilenstein ist, der es ihnen erlaubt, eine Beta im Oktober zuzusagen. Die fünf auf dem `main`-Branch sichtbaren Commits sind zwischen dem 11. und 19. Mai 2026 datiert, mit Commit-Nachrichten, die auf JNI-Erweiterungs-Support, das initiale Scaffold und das README fokussiert sind. Die Release-Kadenz zwischen v0.1.0 (11. Mai) und v0.2.3 (15. Juni) impliziert eine recht aktive Entwicklungsphase, aber die Abwesenheit von Commits auf `main` seit dem 19. Mai legt nahe, dass die Arbeit nach der Umbenennung auf einem Feature-Branch oder in einem privaten Mirror erfolgt, der nach der Quellcode-Veröffentlichung öffentlich gemacht wird.

Die Open-Source-Frage ist diejenige, die Pronskiy markiert hat. Der WeChat-Post verwendet die Phrase „全面开源" (vollständig open-sourced) für die Post-Nationalfeiertag-Veröffentlichung, aber der bestehende Swoole Compiler ist ein kommerzielles Produkt, und das README des `swoole/aot-compiler`-Repositorys verlinkt explizit auf `business.swoole.com/compiler.html`, die kommerzielle Verkaufsseite. Der WeChat-Post selbst schließt mit einer Einladung, den „识沃客服" (Twosee-Kundenservice) WeChat-Account für Entwicklerdiskussionen hinzuzufügen, was der kommerzielle Go-to-Market-Kanal des Unternehmens ist. Die vernünftige Lesart ist, dass die Open-Source-Veröffentlichung eine Community-Edition sein wird, mit einem separaten kommerziellen Produkt obendrauf für Produktionsdeployments, Verschlüsselung und Support, dasselbe Modell, das HHVM verwendete, als es open-sourced wurde. Pronskiys genaue Formulierung in seinem X-Artikel ist, dass „open source nicht free bedeutet, aber ich nehme an, das ist die Implikation", was das richtige Maß an Unsicherheit ist, um es in den Oktober mitzunehmen.

## Pronskiys Kritik und die Language-Fork-Frage

Roman Pronskiys Framing ist die Lesart, die der Rest der Branche zuerst erhalten wird, weil Pronskiy der Leiter von PhpStorm bei JetBrains ist, der IDE, die die meisten professionellen PHP-Entwickler verwenden, und Vorstandsmitglied der PHP Foundation, der Non-Profit-Organisation, die die Leute finanziert, die die Sprache selbst am Leben erhalten. Er ist kein neutraler Beobachter, aber er ist auch der am besten informierte neutrale Beobachter, der nicht im Swoole-Team sitzt. Sein X-Artikel rahmt die Umbenennung in drei Sätzen, die es wert sind, als Einheit gelesen zu werden: „Während Generics bei der Abstimmung scheitern, kommt hier eine Fortsetzung der Swoole-AOT-Compiler-Geschichte (ich habe früher darüber geschrieben). Er ist jetzt offiziell in TypePHP umbenannt. Sie haben es letztes Mal kurz erwähnt, aber jetzt sagen sie es offen: es ist eine eigenständige stark typisierte kompilierte Sprache." Der erste Satz ist der unterbewertete. Die PHP-RFC für Generics in der Sprache selbst scheiterte zur gleichen Zeit zur Abstimmung, in der TypePHP angekündigt wurde, was die Art Timing-Zufall ist, die das Swoole-Team nicht zu inszenieren brauchte, von der es aber profitierte. Der zweite Satz ist die Nachricht. Der dritte Satz ist das Framing.

Sein Abschnitt „what else is cool" ist die positive Lesart. Die drei Merkmale, die er hervorhebt (natives Decimal, typisierte Container, UFCS), sind genau die Merkmale, mit denen das Swoole-Team vorprescht, und Pronskiys Reaktion („Whaaaat?! You could do that all along??") ist die Reaktion, auf die das Team hofft. UFCS insbesondere ist die Art Feature, die Entwickler beim ersten Mal begeistert und dann automatisch zu einem Werkzeug wird, zu dem sie greifen, und die Begleit-Erweiterungsmethode ist der Teil, der das Feature mit bestehendem Code komponibel macht.

Sein „Aber" ist die Lesart, auf die die Branche achten wird. Pronskiy zieht die Linie direkt: „Je weiter es geht, desto weniger ist es PHP. Wir haben das schon gesehen: Facebook hat „schnelles PHP" gemacht → es wurde zu Hack → eine eigenständige Sprache → das Ökosystem spaltete sich → und jetzt bist du hier." Dies ist das Kernargument, und es ist das Argument, das von jedem PHP-Framework-Maintainer, jedem Hosting-Anbieter und jedem Entwickler vorgebracht wird, der bereits entschieden hat, dass PHP eine nicht verhandelbare Einschränkung auf seinem Stack ist. Das Swoole-Team ist in der Position, dieses Argument beantworten zu müssen, und die Antwort muss substanzieller sein als „wir haben eine Dual-Engine".

Es gibt zwei Wege, wie die Antwort gehen kann. Der erste ist, dass die Dual-Engine hält: Jede PHP-Anwendung läuft weiterhin innerhalb einer TypePHP-Binary, und die Sprachmerkmale sind Opt-in-Erweiterungen, die nie die PHP-Kompatibilität brechen. Die vom Swoole-Team erklärte Behauptung einer 100% PHP-Ökosystem-Kompatibilität ist die Wette, und v0.2.3 mit dem selbstgehosteten Compiler, der Unit-Tests besteht, ist der erste Beweis, dass die Wette auf Kurs ist. Der zweite ist, dass die Sprachmerkmale zum Standard werden und die PHP-Kompatibilität zum Legacy-Modus wird, wie Hack von „PHP mit Typannotationen" zu „eine eigenständige Sprache, die zufällig als PHP parsbar ist" überging. Die Umbenennung von „Swoole AOT" zu „TypePHP" ist das frühe Signal, dass der zweite Weg mindestens plausibel ist, weil das Team das Projekt nicht mehr als einen Compiler für PHP framet, sondern als eine eigenständige Sprache.

Die Oktober-Veröffentlichung wird der Wendepunkt sein. Wenn der Quellcode unter einer permissiven Lizenz veröffentlicht wird (MIT, Apache-2.0 oder ähnlich), wenn die Dokumentation TypePHP als eigenständige Sprache und das bestehende Swoole AOT als Kompatibilitäts-Shim beschreibt, und wenn die Sprachmerkmale als primär statt als Opt-in präsentiert werden, ist das Projekt auf dem Language-Fork-Pfad. Wenn die Quelle unter einer Source-Available-Lizenz veröffentlicht wird, wenn die Dokumentation TypePHP im PHP-Ökosystem-Framing hält, und wenn die Sprachmerkmale als Opt-in-Erweiterungen präsentiert werden, ist das Projekt auf dem Kompatibilitätsschicht-Pfad. Die Binary-Releases und der WeChat-Post deuten beide in Richtung Language-Fork-Pfad. Die tatsächlichen Lizenzbedingungen, wenn sie erscheinen, werden bestätigen, in welche Richtung das Team sich bekennt.

## Worauf zu achten ist

Das nächste Signal ist die Quellcode-Veröffentlichung auf dem `swoole/aot-compiler`-Repository. Das Swoole-Team hat sich verpflichtet, die Quelle „国庆节后" (nach dem Nationalfeiertag, der der 1. Oktober 2026 ist) hochzuladen, und die Lizenzbedingungen, die diesem Upload beigefügt sind, sind der einzelne wichtigste Datenpunkt. Eine permissive Lizenz (MIT, Apache-2.0, BSD) signalisiert, dass das Team sich zum Language-Fork-Pfad mit dem bestehenden PHP-Ökosystem als Migrationsziel bekennt. Eine Source-Available-Lizenz (die BSL, die SSPL, die Business Source License oder eine benutzerdefinierte Swoole-kommerzielle Lizenz) signalisiert, dass das Team sich zum Language-Fork-Pfad mit einem kommerziellen Produkt obendrauf bekennt, so wie HashiCorp und Elastic es getan haben.

Das zweite Signal ist die Dokumentation unter `doc.swoole.com/@aot-compiler/`, die zum Zeitpunkt des Schreibens einen 404 zurückgibt. Wenn die Dokumentation live geht, wird die Art, wie das Projekt geframed wird, das Language-Fork-Framing des WeChat-Posts bestätigen oder widersprechen. Achten Sie speziell darauf, ob die Dokumentation das Projekt einen „Compiler für PHP" oder eine „kompilierte Sprache mit PHP-Syntax-Kompatibilität" nennt, und ob die Sprachmerkmale (Decimal, typisierte Container, UFCS) als zentral oder als Opt-in-Erweiterungen präsentiert werden.

Das dritte Signal ist die `phpx`-Bibliothek. Der C++-Wrapper des Swoole-Teams für die Zend-API ist seit 2017 unter Apache-2.0 lizenziert und ist das Fundament der C++-ABI-Integration des AOT-Compilers. Wenn der AOT-Compiler unter einer permissiven Lizenz veröffentlicht wird, aber die phpx-Bibliothek in eine andere Lizenz verschoben wird, oder wenn phpx in ein separates Projekt für die Open-Source-Community geforkt wird, ist das ein Signal über die Grenze zwischen den Open-Source- und kommerziellen Produkten. Das aktuelle `swoole/phpx`-Repository hat 856 Sterne und wird aktiv gepflegt, und die C++-Wrapper, die es bereitstellt, sind genau die Wrapper, die ein Drittentwickler brauchen würde, um seine eigene C++/TypePHP-Brücke zu bauen.

Das vierte Signal ist die breitere Reaktion der PHP-Community. Die PHP Foundation hat noch keine Stellungnahme zur Umbenennung abgegeben, und das Schweigen ist selbst ein Signal. Die Foundation finanziert die Leute, die die PHP-Sprache selbst warten, und eine eigenständige kompilierte Sprache, die PHP-Syntax verwendet, ist eine kompetitive Entwicklung für die Erzählung der Foundation von PHP als einzelner sich entwickelnder Sprache. Die Antwort der Foundation, wenn sie kommt, wird klären, ob die Foundation TypePHP als gesunde Ergänzung des PHP-Ökosystems sieht (so wie Swoole im engeren Sinne seit Jahren behandelt wurde) oder als Fork, der entweder absorbiert oder in Opposition gesetzt werden muss. Pronskiys Artikel ist eine Lesart; die eventuelle Antwort der Foundation wird die institutionelle sein.

Das fünfte Signal ist die Adoption in der chinesischen PHP-Community. Der Post des offiziellen WeChat-Kontos ist der erste Zug; die Kundenservice-Einladung am Ende ist der zweite. Das Swoole-Team hat ein tiefes Netzwerk in der chinesischen PHP-Community durch die bestehende Swoole-Laufzeit, die chinesischen Mitglieder der PHP Foundation und den breiteren PHP-China-Konferenz-Zirkel. Wenn die Oktober-Beta landet und die chinesische PHP-Community sie aufgreift, wie sie 2014 Swoole aufgegriffen hat, hat das Projekt eine echte Basis. Wenn die Community es als Kuriosität behandelt und abwartet, ob die Sprachmerkmale die unvermeidlichen Kompatibilitätsprobleme überleben, hat das Projekt dieselbe Zukunft wie KPHP: technisch exzellent, Nischen-Adoption, langfristige Wartung durch das Originalteam.

Das letzte Signal ist die Performance des Compilers in der realen Welt. Die Behauptung „zehn- bis hundertfach schneller als PHP" ist die Schlagzeilenzahl, und sie wurde noch nicht unabhängig verifiziert. Die eigenen Benchmarks des Swoole-Teams, die vermutlich mit der Quellcode-Veröffentlichung kommen werden, werden die Baseline setzen. Unabhängige Benchmarks von außerhalb des Teams, besonders zu den typischen Webanwendungs-Workloads (Request-Handling, Datenbankabfragen, JSON-Serialisierung, Template-Rendering), werden bestimmen, ob die Performance-Geschichte in der Produktion hält. Die Dual-Engine kompliziert die Benchmark-Geschichte, weil dasselbe Binary konfiguriert werden kann, um im vollständig kompilierten Modus, im vollständig interpretierten Modus oder in einem Hybrid der beiden zu laufen, und die relative Performance der drei Modi ist die Zahl, die das Ökosystem verwenden wird, um die Build-vs-Buy-Entscheidung zu treffen.

Die Oktober-Veröffentlichung ist der Termin. Bis dahin ist das Nützlichste, was ein PHP-Entwickler tun kann, die v0.2.3-Binary herunterzuladen, das `examples/tetris-sdl`- oder `examples/jni`-Beispiel dagegen zu kompilieren und sich eine persönliche Meinung zu bilden, ob die Sprachmerkmale den Kompromiss wert sind. Das Swoole-Team hat die Testversion genau verfügbar gemacht, um diese frühen Lesarten zu säen, und der Diskurs um das Projekt im Oktober wird davon geformt werden, was die frühen Adopter finden.