Hack im Wettbewerb mit etablierten Gegenspielern

5 gute Gründe gegen Hack
Kommentare

In einem Blogpost stellt Manuel Lemos eine gewagte Theorie auf: Die Sprache Hack sei all das, was PHP immer sein sollte. Zwar mag diese Aussage, bezogen auf einige Features, durchaus richtig sein, dennoch kann es nicht schaden, etwas Ruhe in die Diskussion zu bringen und sich zu fragen: Warum sollte Hack PHP den Garaus machen?

Seit letzter Woche bringt Facebooks Hack einige Unruhe in die Community. Viel wurde geschrieben über die Alternative zu PHP in der HHVM, viel über die Vorteile wie statische Typisierung, Annotations oder asnychrone Programmierung geredet. Doch langt das aus, um PHP vom Thron zu verstoßen?

Feature-Overkill?

Hack bietet zweifelsohne viele Vorteile gegenüber PHP, zum Teil auch Funktionalitäten, die in RFCs bereits abgelehnt wurden – Annotaions sind nur ein Beispiel dafür; die Diskussion dazu wurde bereits im September 2010 geführt.

Besonders beliebt und auch im Sinne der Softwarequalität von hohem Stellenwert sind Generics und die Möglichkeit, eine starke Typisierung anzuwenden – ohne jedoch dazu gezwungen zu werden. Hinzu kommen Collections, XHP und die Keywords await und async für asynchrone Entwicklung.

Hinzu kommt die entsprechende Umgebung dafür: Die HipHop Virtual Machine, die zum Teil enorme Performance-Gewinne ermöglicht.

Bei all dem stellen sich natürlich die verschiedensten Fragen. Wer profitiert beispielsweise von den Features? Und kann man wirklich darauf vertrauen, dass Facebook an der Technologie festhält? Genau zu diesen Themen äußert sich Johannes Schlüter, Release Manager von PHP 5.3:

Johannes SchlüterJohannes SchlüterWie jede neue Technologie ist HHVM zunächst nur für einen kleinen Anwenderkreis für Produktionsumgebungen relevant. In der Masse fehlen, neben 101-Prozentiger Kompatibilität, derzeit die nötige Erfahrung für Betrieb und Troubleshooting – diese existiert nur innerhalb von Facebook. Nur wenige Anwender wollen und können es sich leisten, bei Problemen alleine dazustehen. Zudem fehlt derzeit eine Community, die das Projekt übernehmen kann, falls Facebook entscheidet, die Entwicklung nicht weiter fortzusetzen. Das Facebook solche Projekte mitunter einstellt, konnte man beim „klassischen“ „Hiphop Compiler“, Facebooks PHP-nach-C++-Übersetzer, sehen. HHc wurde laut vorgestellt und ist dann bald still und heimlich eingestellt worden, um mehr als ein Jahr später von HHVM ersetzt zu werden.

Ein Wechsel von PHP auf HHVMs PHP-Implementierung führt zudem auch dazu, dass man Teile des PHP-Environments nicht mehr nutzen kann. Auch wenn Facebook an einem PHP-kompatiblen Extension API arbeitet, sind längst nicht alle Extensions mit HHVM nutzbar. Weder alle aus PHP-Core noch aus PECL. So ist beispielsweise die Nutzung von mysqlnd-Plugins wie dem Query Cache, der einer Anwendung 100 Prozent transparent einen MySQL-Query-Cache unterschiebt und somit ohne Änderung der Anwendung deutlich höhere Leistungssteigerungen als der Wechsel von PHP auf HHVM liefern kann, nicht möglich.

Hack als neue Sprache stellt nun HHVMs PHP-Modus weiter in Frage: Wenn Facebook voll auf Hack läuft, wie weit geht deren Interesse an der Sprache PHP, und opfern sie das eventuell, um HHVM weiter für Hack zu tunen? Das ist für außenstehende nur schwer einzuschätzen. Es kann sein, dass Facebook auf Dauer Verwendung dafür hat, muss aber nicht. Bindende Aussagen gibt es nicht.

Hack selbst ist nun ein typsicheres PHP, also eine Sprache, die mit PHP interagieren kann, sich davon aber abhebt. Eine Mischung dieser beiden Welten ist möglich, aber nur sehr eingeschränkt sinnig. Aus Erfahrungen in der Java-Welt, mit verschiedenen sprachen auf der JVM, kann man lernen, dass die dynamisch typisierte Sprache eher im Frontendbereich einzusetzen ist. Bei einem Wechsel auf Hack fehlen einem somit die ganzen Backendbibliotheken – gerade jetzt, wo wir mit Composer und packagist.org eine Infrastruktur bekommen haben, welche die Verteilung dieser ermöglicht und geradezu zu einem Boom dieser geführt hat.

Zum Schluss sei angemerkt, dass es eine 100 Prozent bewusste, zentrale Designentscheidung von PHP ist, nicht fest typisiert zu sein. PHP ist eine Glue-Sprache für das Web. Auf der einen Seite kommen Web-Requests rein – diese sind Strings, auch wenn es nummerische Daten, etc. repräsentiert. Das wird in SQL-Abfragen, die Strings sind, verarbeitet und das Ergebnis von der Datenbank, wo viele Systeme auch für nummerische Daten Strings liefern, als String in HTML verpackt. Da Konvertierungshürden rauszunehmen, kann die Entwicklungsgeschwindigkeit steigern. Es erfordert bei komplexeren Systemen jedoch höhere Disziplin.

Wenn ich mich entscheide, dass für mein Problem eine statisch typisierte Sprache angebracht ist, ist immer noch zu überlegen, ob Hack der richtige Weg ist.

Ja, wenn man von PHP kommt ist der Weg nicht weit, andere Sprachen bieten jedoch umfangreicheres Environment mit Bibliotheken etc., die derzeit für Hack noch fehlen.

Zusammengefasst sei gesagt, dass Hack eine interessante Sprache und HHVM eine interessante Technologie ist, sich aber in einem Wettbewerb mit etablierten Gegenspielern, nicht nur PHP, befindet und sich erst einmal beweisen muss.

Hack vs. PHP

Zieht man nur einmal PHP in Betracht, muss sich Hack mit einer Konkurrenz messen, die seit Jahren den Markt beherrscht. Und hier den „Durchbruch“ zu schaffen, wird aus mehreren Gründen kompliziert:

  1. Zwar mag es PHP-Entwicklern durchaus leicht fallen, ihre Applikationen mit relativ wenig Aufwand nach Hack zu migrieren; anders herum wird jedoch kein Schuh daraus. Sobald man Hack-spezifische Funktionalitäten verwendet, ist der Code nicht mehr „im klassischen“ PHP, also mit der Zend Engine, zu verwenden.
  2. Deutlich über 80 Prozent des Webs wird von PHP angetrieben – darunter ebenso riesige Projekte wie auch kleinere Applikationen bis hin zu unzähligen Gästebuchskripten. Abgesehen von der schieren Masse, ist es natürlich eine Frage der Infrastruktur dahinter. PHP findet man heute auf beinahe jedem Server – die HHVM kann das nicht von sich behaupten; und ohne die HHVM kein Hack. Bis hier eine kritische Marktdurchdringung erreicht wird, werden Jahre vergehen.
  3. Facebook bietet in der HHVM Entwicklern zwar die Möglichkeit, mithilfe des HNI (HHVM Native Interface) PHP-Extensions in PHP statt in C++ zu schreiben, dennoch fehlen aktuell noch zahlreiche Extensions, um auch nur annähernd von einer guten Abdeckung reden zu können. Ein Projekt, das auf einer in Hack fehlenden Extension basiert, wird den Umstieg also kaum auf sich nehmen.
  4. Die Vergangenheit hat bereits bewiesen, dass Facebook keine große Scheu davor hat, Technologien fallenzulassen. Aktuell mag die Kombination aus Hack und der HHVM für den Social-Media-Riesen funktionieren, es ist jedoch nicht gesagt, dass das auch in Zukunft so bleiben wird. Kein noch so großes Projekt wird sich jetzt auf das dünne Eis begeben und komplett switchen, auch wenn ein Teilumstieg – also nur auf die HHVM, ohne die Sprache zu wechseln – durchaus eine mit Vorsicht zu genießende Option darstellt.
  5. Zu guter Letzt könnte es durchaus sein, dass Facebook sich früher oder später dagegen entscheidet, Hack Open Source laufen zu lassen. Und sollte das der Fall sein, dürften einige Projekte, die keinen entsprechenden Fallback haben, vor großen Problemen stehen.

Wie man es auch dreht oder wendet: Die Sprache Hack ist ebenso interessant wie die HHVM, auf der sie basiert. Vor allem die Nähe zu PHP dürfte zumindest das Nachdenken über einen Umstieg für viele interessant erscheinen lassen.

Dennoch sollte die oberste Priorität lauten, Ruhe zu bewahren. Aktuell steht nicht zu befürchten, dass wir uns in einem absehbaren Zeitrahmen mit einer Fragmentierung zwischen PHP und Hack konfrontiert sehen werden.

Und wer weiß, vielleicht regen die Entwicklungen das PHP-Core-Team in einigen Bereichen zum umdenken an.

Aufmacherbild: black knight chess piece on background von Shutterstock / Urheberrecht: Dima Sobko

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -