Adieu HHVM, et merci bien pour le poisson

closeCet article a été publié il y a 5 ans 1 mois 2 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

HHVM, si vous n’en avez jamais entendu parler, est un environnement d’interprétation et de compilation à la volée de code logiciel développé par Facebook pour ses propres besoins et publiés en open-source. Sa popularité venait du fait qu’il apportait, à l’époque de sa découverte, une compatibilité partielle mais suffisamment étendue du langage PHP, qui reste le plus populaire dans le monde du web, avec des performances bien supérieures au moteur d’exécution officiel. Mais ça, c’était avant.

Le Hack, un dérivé de PHP

La compatibilité partielle de la HipHop Virtual Machine avec PHP ne sortait pas ne nulle part : Facebook cherche à améliorer l’exécution du code PHP qu’il exploite pour le réseau social aux plus d’un milliard d’utilisateurs réels. Pour différentes raisons, plutôt que d’aider à pousser le développement de PHP 7 sur lequel je reviendrai tout à l’heure, Facebook planche d’abord sur un environnement d’exécution optimisé pour le code qu’il écrit. HHVM dans ses premières itérations se concentre donc uniquement sur les fonctions que Facebook utilise. Jusqu’à voir que certaines limitations ne peuvent pas seulement être levées par le compilateur et que le langage doit évoluer. Le Hack était né, dérivé de PHP, le langage et l’environnement d’exécution sont donc très liés, mais le support de PHP dans une certaine mesure était facilité, puisque la base des deux étaient la même (la version 5.6 était toute jeune, la version 7 à peine en développement).

Le principal intérêt, pour les aventureux voulant tout de même l’exploiter avec PHP, résidait alors principalement dans les performances qui dépassaient de loin celles d’un PHP-FPM qui représentait le Graal de l’époque. j’ai moi-même brièvement utilisé HHVM et je vous en avait fait un petit comparatif. J’ai également eu à gérer une petite incompatibilité avec PHPMyAdmin, qui traduisait bien les différences parfois insolubles entre les deux protagonistes.

Ça poutrait bien fort

La fin d’une époque

En effet, Facebook vient de publier la version 4 d’HHVM, qui continue et entérine la fin du support de PHP pour se concentrer définitivement sur le Hack, un choix qui est logique selon moi vu les objectifs du runtime, qui ne peut pas indéfiniment supporter correctement les deux langages maintenant qu’ils ont bien dérivé chacun de leur côté. Le développement a beau être open-source, la majorité du boulot est à mon avis encore fortement piloté et nourri par les ingénieurs de Facebook, et comme n’importe quelle société, doit gérer des budgets de développement qui tout simplement exploseraient, continuer le support de PHP devient maintenant un non-sens technique et économique.

A noter que tout n’est pas supprimé d’un coup, mais la couverture fonctionnelle a déjà été rapidement castrée. Déjà, PHP7 n’a même pas été considéré, là le support est officiellement abandonné. Ça pourra encore fonctionner un peu, mais sauf surprise de dernière minute la prochaine version 4.1 ne comprendra plus du tout les scripts qui commencent par « <?php ». L’extension même des fichiers doit maintenant être obligatoirement .hack pour les fichiers écrits dans ce langage, tout à fait logique pour plein de raisons d’ailleurs.

On est bien avec PHP7 en fait

En effet, depuis, PHP 7.0 a été publié et a dépoussiéré pas mal de choses, en particulier au niveau des performances. Pendant les dernières étapes de son développement on a d’ailleurs vu les développeurs d’HHVM et PHP-FPM se tirer la bourre, pour le bien de tous au final puisque le gain était énorme, avec un PHP7 au niveau voire meilleur qu’HHVM sur certains scénarios d’exécution. J’ai moi-même vite rebasculé dessus car j’avais des soucis de stabilité avec HHVM, que je n’avais jamais vraiment investigué.

Et surtout, les développeurs de PHP ne se sont pas reposés sur leurs lauriers, PHP 7.1, 7.2, et désormais 7.3 ont continué de chercher entre autres choses une amélioration de performances, plus ou moins marquée à chaque étape, PHP 7.2 a introduit de la crypto robuste, moderne ET performante dans vos programmes PHP via l’extension sodium, bref, il n’y a plus aucune raison de se faire mal avec un environnement d’exécution qui ne considère plus vos applications comme dignes de lui, et revenir au standard vous donnera pleinement satisfaction. Sinon c’est que le langage que vous utilisez n’est peut-être plus adapté.

Attention, j’ai vu passer quantité d’alertes en fin d’année avec la fin du support simultané de PHP 5.6 ET PHP 7.0. Si leur fin de vie n’augure rien de bon dans les mois à venir en termes de sécurité, vous avez encore le temps, si vous n’avez pas encore finalisé votre migration, de vous pencher sur ce qui va vous péter à la tronche et aux corrections à apporter pour basculer sur une version supportée. Et pour les plus inquiets, je vous laisse imaginer le stress au boulot avec plusieurs de nos clients encore sur PHP 5.2, 5.3, et 5.4. Avec des machines sans reboot depuis 8 ans, ou un record d’ancienneté logicielle avec une Debian 3.1…

2 Commentaires
Le plus ancien
Le plus récent
Commentaires en ligne
Afficher tous les commentaires
un admin en passant
un admin en passant
24/02/2019 12:10

Rigolo on a les mêmes records d’ancienneté dans ma boite
Et on est pas prêt de le décommissionner le Deb3.1 (m’enfin il doit reboot plus ou moins toutes les semaines pour instabilité ou piratage…)

Jiab77
Jiab77
10/07/2019 17:52

ahahah respect pour les migrations à faire et merci pour cet excellent article.