IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« Pourquoi on est repassé de Go à PHP ? », Danny van Kooten, l'éditeur de MailChimp nous livre les raisons
De ce rebasculement

Le , par Bill Fassinou

257PARTAGES

15  0 
En avril 2017, Danny van Kooten, un développeur indépendant, prenait la décision de réécrire en Go l'application Laravel qui alimente Boxzilla, un plugin pour WordPress qui permet de créer des formulaires MailChimp ayant plus d'un million d'utilisateurs. Le développeur précisait qu'il avait pris du plaisir à coder son application en Go. Rappelons au passage que Go est un langage de programmation compilé et concurrent inspiré de C et Pascal. Ce langage a été développé par Google et veut faciliter et accélérer la programmation à grande échelle. C'est un langage qui vise aussi la rapidité d'exécution, indispensable à la programmation système. Il considère le multithreading comme le moyen le plus robuste d'assurer sur les processeurs actuels cette rapidité tout en rendant la maintenance facile par séparation de tâches simples exécutées indépendamment.

Pourquoi avoir laissé PHP pour Go ?

Après avoir développé son application en Go, Kooten trouvait que le résultat final était une énorme amélioration par rapport à l'ancienne application (développé en PHP) avec une meilleure performance, un déploiement plus facile et une couverture de test plus étendue. Le développeur explique que son application était relativement simple. C'était une API et un gestionnaire de compte relativement simple, pilotée par une base de données, où les utilisateurs peuvent se connecter pour télécharger le produit, consulter leurs factures ou mettre à jour leur méthode de paiement, dit-il. Laravel l'avait bien aidé à développer, mais Kooten trouvait que certaines choses « ont toujours semblé trop compliquées » à faire.


« C'est un plaisir d'écrire du code Go, l'outillage est incroyable et il n'est pas seulement rapide à développer, le résultat final est généralement très rapide aussi. Le simple fait de lire le but du projet Go m'a convaincu sur le langage. Je pense que nous verrons un bon nombre de personnes passer des langages de typage dynamique comme PHP, Python et JavaScript à Go dans les prochaines années. Migrer le code vers Go consistait principalement à obtenir l'interaction de la base de données et à porter les modèles Blade vers quelque chose que nous pourrions utiliser dans Go », écrivait-il.

Pourquoi avoir renoncé à Go pour revenir à PHP ?

Contre toute attente, Danny van Kooten annonce dans un billet de blog le lundi dernier que ses applications de boutique sont de nouveau alimentées par PHP. Pourquoi ce revirement soudain pourrait-on se demander ? Eh bien, la raison est simple. Le développeur trouve que PHP s'est beaucoup amélioré au cours des trois dernières années. « Le langage a ajouté des déclarations de type argument scalaire, des déclarations de type retour, des exceptions multi-catch, des améliorations de performances impressionnantes et bien d'autres améliorations plus générales », dit-il. Kooten a été principalement séduit par Symfony 4.

Citation Envoyé par Danny van Kooten
J'ai toujours été un grand fan de la promesse de compatibilité de Symfony et leur impressionnante expérience de 13 ans prouve qu'ils le pensent vraiment. Alors quand Symfony 4 est sorti et que j'ai entendu de bonnes choses à son sujet, je l'ai pris pour un essai en y implémentant une toute petite partie de notre application. Comme conclusion, j'ai remarqué que beaucoup d'efforts ont été consacrés à la simplification de l'installation, ce qui a accéléré le démarrage d'une application Symfony avec beaucoup moins de travail pour configurer les bundles. Il rivalise maintenant avec le développement rapide de Laravel tout en encourageant des pratiques de développement décentes. Et il est très performant.

Il a été relativement facile de porter notre ancienne application Laravel sur Symfony, d'implémenter de nouvelles fonctionnalités de la version Go de notre application et d'annuler certains des raccourcis que j'avais pris auparavant (la plupart grâce aux aides globales de Laravel). Un bel effet secondaire est que j'ai réussi à augmenter substantiellement notre couverture de test dans le processus. Écrire la même application en termes de fonctionnalités pour la deuxième fois une troisième fois est vraiment utile à cet égard.

La barre de débogage de Symfony est un outil incroyable. Il vous montre ce qui s'est passé pendant le trajet de la demande à la réponse, vous informe des avertissements et des déprédations et est livré avec un profileur intégré que vous pouvez facilement connecter à des parties de benchmark de votre propre code. Après avoir appris le composant Form de Symfony, je préfère ne plus m'en passer. Il est donc trivial de rendre un formulaire accessible qui peut être réutilisé à plusieurs endroits, de valider le formulaire lors de sa soumission, puis de remplir un objet PHP à partir des données du formulaire en toute sécurité.
Toutefois, Danny van Kooten tient à préciser que ce n'est pas parce que Go l'a déçu qu'il a changé de langage de développement. Au contraire, il trouve toujours Go très génial. « Honnêtement, Go est génial. Sa simplicité est rafraîchissante et vous ne pouvez pas vous approcher de ce genre de performance avec PHP 1, je la choisirais quand même si nous avons besoin d'une petite API ou quelque chose qui nécessite un haut débit », dit-il.

Pour certains internautes, passer de PHP à Go ne semble pas être une bonne idée à leur avis. Pour cause, disent-ils, les fichiers PHP peuvent être déployés indépendamment, échangés ou mis à jour en direct, aucune compilation des fichiers PHP n'est nécessaire. Pour eux, si ce n'est que pour compiler et déployer un système entier pour changer un seul point d'extrémité d'une application est comme revenir en arrière après avoir utilisé PHP.

Source : Billet de blog

Et vous ?

Qu'en pensez-vous ?
Quel langage de programmation Web côté serveur préférez-vous ? Pourquoi ?
Vous est-il déjà arrivé de quitter PHP pour y revenir après ? Pour quelles raisons ?

Voir aussi

Quels sont les langages de programmation les plus utilisés par les développeurs ? Une analyse des évènements publics sur GitHub

PHP est utilisé par plus de 80 % des sites, toutefois 96 % de ces sites utilisent encore la version 5 du langage, selon un rapport de la W3Techs

PHP 7.4 devrait être rendu disponible vers la fin de cette année voici un aperçu des nouveautés qui pourraient y figurer

W3Tech : plus de 60 % des sites Web tournent sur PHP 5.x une version qui ne sera plus supportée après le 31 décembre 2018

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 08/02/2019 à 18:19
le dernier argument évoqué est justement la force et à la fois la faiblesse de PHP, quel programme PHP n'a pas râlé pour une erreur de syntaxe qui n'est apparue que longtemps après la mise en oeuvre dans une partie du code peu sollicité ?

les langages compilés ont cette énorme avantage d'une validation de l'ensemble du code de l'application une bonne fois pour toute, ensuite il peu rester des bugs, mais jamais d'erreur de syntaxe...sur les langages interprété, ce n'est qu'en exécutant chaque portion de code dans chaque condition d'utilisation (vive les includes) qu'on va pouvoir s'assurer que tout fonctionne correctement.

l'autre chose pénible c'est que lorsque l'on met à jour le moteur PHP, les scripts peuvent ne plus fonctionner car ils utilisent une fonction dépréciée, ou dont le fonctionnement a été modifié...ça n'arrivera jamais sur un code compilé, le problème peut éventuellement se produire sur une recompilation, mais la version en production ne bougera pas.

j'utilise cependant PHP pour presque tous mes hébergements web car ils sont sur du mutualisé OVH et que c'est du coup beaucoup plus simple à mettre en oeuvre...même si je croise les doigts quand une version de PHP est abandonnée et que je dois pousser une nouvelle version.
6  1 
Avatar de rawsrc
Expert éminent sénior https://www.developpez.com
Le 08/02/2019 à 19:27
Jamais touché à Go, par contre je peux vous assurer que dans le monde pro, PHP 7+ est considéré comme un solide langage de dév. Depuis l'apparition du typage statique, j'ai même vu des dev java s'y remettre, c'est dire...
Les perfs en général sont impressionnantes "out of the box", pas besoin de tripatouiller. Et cela va continuer : PHP 8.0 annonce que du bon : usage massif d'un compilateur JIT et alors là : roulements de tambour : un mini serveur d'applications natif qui permettra de garder à disposition les fichiers compilés en mémoire entre les appels ! C'est une révolution profonde dans la mesure où PHP s'éloigne de son fonctionnement originel stateless.

Bref, PHP récupère des développeurs et des projets dans les entreprises, que du bon je vous dis
Et les perfs vont encore grimper méchamment (pour tout ce qui est à gros trafic, c'est tip-top)
5  0 
Avatar de archqt
Membre émérite https://www.developpez.com
Le 09/02/2019 à 16:52
Citation Envoyé par stef-13013 Voir le message
Boaf, il aurait fait tout ça en Python dès le départ et le problème ne se posait même pas
(je rigole, ça va...)
Sauf qu'il aurait fallu multiplier les serveurs pour pallier à la lenteur de python
4  0 
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 11/02/2019 à 9:16
Citation Envoyé par dad3zero Voir le message
Heu… Est-il nécessaire en 2019 de rappeler que "compilation" n'est pas un synonyme de "validation" ? Et que les tests sont le principal outil de validation du bon fonctionnement ?
je répond à ceci
les fichiers PHP peuvent être déployés indépendamment, échangés ou mis à jour en direct, aucune compilation des fichiers PHP n'est nécessaire
par ailleurs je n'ai jamais prétendu qu'une application compilée ne pouvais pas avoir de bug, la compilation assure simplement qu'il n'y a aucune erreur de syntaxe (en plus des warnings qui pointent les faiblesses du code).
4  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 11/02/2019 à 11:45
Citation Envoyé par dad3zero Voir le message
Citation Envoyé par Paul TOTH Voir le message
le dernier argument évoqué est justement la force et à la fois la faiblesse de PHP, quel programme PHP n'a pas râlé pour une erreur de syntaxe qui n'est apparue que longtemps après la mise en œuvre dans une partie du code peu sollicité ?

les langages compilés ont cette énorme avantage d'une validation de l'ensemble du code de l'application une bonne fois pour toute, ensuite il peu rester des bugs, mais jamais d'erreur de syntaxe...sur les langages interprété, ce n'est qu'en exécutant chaque portion de code dans chaque condition d'utilisation (vive les includes) qu'on va pouvoir s'assurer que tout fonctionne correctement.
Heu… Est-il nécessaire en 2019 de rappeler que "compilation" n'est pas un synonyme de "validation" ? Et que les tests sont le principal outil de validation du bon fonctionnement ?
Il y a bien une confusion sur la notion de compilation, mais je vois que dad3zero s'est ramassé un -3. Du coup, je vais rebondir dessus en détaillant.

Prenons l'exemple de Python que je connais mieux que PHP. Python est, à la base, un langage interprété. Pourtant :
  • On peut lancer une analyse statique du code avec Pylint. Pylint est capable de détecter des appels de fonctions non définies et la lecture de variables non déclarées. Il détecte cela simplement en lisant le code, sans exécuter chaque portion. Pylint analyse aussi les problèmes de style. Mais Pylint ne compile pas du code Python.
  • On peut aussi lancer une analyse statique du code avec mypy. mypy détecte aussi des appels de fonctions non définies et la lecture de variables non déclarées, mais permet en plus de détecter des erreurs de type, seulement en lisant le code. Cela s'appuie sur la notion de typage statique. Mais mypy ne compile pas du code Python.
  • On peut aussi compiler du code Python avec Nuitka. Nuitka génère bien un ".exe" à partir de code Python.


Il ne faut pas confondre :
  • la compilation, qui consiste à transformer du code d'un langage vers un autre, en général du langage machine et
  • l'analyse statique du code, qui permet de détecter des erreurs sans l'exécuter.
3  0 
Avatar de
https://www.developpez.com
Le 09/02/2019 à 12:05
Citation Envoyé par rawsrc Voir le message
Et cela va continuer : PHP 8.0 annonce que du bon : usage massif d'un compilateur JIT et alors là : roulements de tambour : un mini serveur d'applications natif qui permettra de garder à disposition les fichiers compilés en mémoire entre les appels ! C'est une révolution profonde dans la mesure où PHP s'éloigne de son fonctionnement originel stateless.
Le fonctionnement stateless de PHP est en partie ce qui rend le langage à la fois si permissif et résistant. Si une instance de PHP plante, il suffit de la tuer et ça n'impacte pas (enfin peu) le serveur. A mon avis la migration d'une appli tournant sur PHP actuel à une future version stateful va réserver des belles surprises au niveau des memory leaks, comme par exemple les ressources non fermés comme les fichiers ou une connexion à une BDD.

En revanche ça ouvre la voie à un nodeJS-like pour PHP et ça c'est très cool. Je sais qu'il existe déjà des solutions pour cela comme Ratchet, mais c'est se battre contre le langage lui même pour en arriver là (et autant utiliser autre chose du coup).
2  0 
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 11/02/2019 à 14:22
Citation Envoyé par Pyramidev Voir le message
Il y a bien une confusion sur la notion de compilation, mais je vois que dad3zero s'est ramassé un -3. Du coup, je vais rebondir dessus en détaillant.
avec plaisir, je suis ouvert à la discussion

Citation Envoyé par Pyramidev Voir le message
Prenons l'exemple de Python que je connais mieux que PHP. Python est, à la base, un langage interprété. Pourtant :
  • On peut lancer une analyse statique du code avec Pylint. Pylint est capable de détecter des appels de fonctions non définies et la lecture de variables non déclarées. Il détecte cela simplement en lisant le code, sans exécuter chaque portion. Pylint analyse aussi les problèmes de style. Mais Pylint ne compile pas du code Python.
  • On peut aussi lancer une analyse statique du code avec mypy. mypy détecte aussi des appels de fonctions non définies et la lecture de variables non déclarées, mais permet en plus de détecter des erreurs de type, seulement en lisant le code. Cela s'appuie sur la notion de typage statique. Mais mypy ne compile pas du code Python.
  • On peut aussi compiler du code Python avec Nuitka. Nuitka génère bien un ".exe" à partir de code Python.


Il ne faut pas confondre :
  • la compilation, qui consiste à transformer du code d'un langage vers un autre, en général du langage machine et
  • l'analyse statique du code, qui permet de détecter des erreurs sans l'exécuter.
alors je connais mieux PHP que Python, mais ce que tu décris ressemble méchamment à une compilation, quand bien même le but n'est pas de produire un exécutable...ce qui n'est d'ailleurs pas la finalité d'un compilateur, c'est d'ailleurs bien souvent la tâche d'un linker. Mais tous les codes PHP en sont pas "compilables" car c'est un langage très souple.
Si j'en crois WikiPedia, Python "favorise la programmation impérative structurée, fonctionnelle et orientée objet. Il est doté d'un typage dynamique fort" alors que PHP "est un langage peu typé et souple et donc facile à apprendre par un débutant"...certes il a beaucoup évolué depuis ses débuts, mais il garde toute sa souplesse.

Citation Envoyé par dad3zero Voir le message
Ben… Non, j'insiste, la compilation assure simplement la transformation de code source en binaire machine, et je ne vais pas paraphraser Pyramidev pour la justification.
la définition est approximative puisque tu peux très bien compiler un code source C++ en Javascript par exemple, mais quoi qu'il en soit, la transformation n'a rien de simple, elle assure la totale cohérence du code source pour le transformer en quelque chose de totalement différent et qui ne permet généralement l'opération inverse (bien qu'on trouve des décompilateurs pour langages évolués).

Citation Envoyé par dad3zero Voir le message
P.S. je vais quand même rajouter une anecdote, dans les affirmations de la sorte, je me projette toujours il y a 20 ans où certaines compilations étaient réalisées sur des supercalculateurs sur lesquels vous n'aviez qu'un créneau réduit par jour. Êtes-vous êtes prêt à considérer que vous pouvez sacrifier une journée et votre slot pour valider la syntaxe de votre code ?
alors il y a 20 ans on aurait rit au nez d'un développeur qui aurait prétendu faire tourner une application de gestion dans un navigateur avec le même langage interprété côté client et serveur...mais on pouvait déjà compiler des projets Pascal complets en quelques secondes.
2  0 
Avatar de stef-13013
Membre actif https://www.developpez.com
Le 08/02/2019 à 18:50
Boaf, il aurait fait tout ça en Python dès le départ et le problème ne se posait même pas
(je rigole, ça va...)
1  0 
Avatar de dad3zero
Membre actif https://www.developpez.com
Le 10/02/2019 à 15:51
Citation Envoyé par Paul TOTH Voir le message
le dernier argument évoqué est justement la force et à la fois la faiblesse de PHP, quel programme PHP n'a pas râlé pour une erreur de syntaxe qui n'est apparue que longtemps après la mise en oeuvre dans une partie du code peu sollicité ?

les langages compilés ont cette énorme avantage d'une validation de l'ensemble du code de l'application une bonne fois pour toute, ensuite il peu rester des bugs, mais jamais d'erreur de syntaxe...sur les langages interprété, ce n'est qu'en exécutant chaque portion de code dans chaque condition d'utilisation (vive les includes) qu'on va pouvoir s'assurer que tout fonctionne correctement.
Heu… Est-il nécessaire en 2019 de rappeler que "compilation" n'est pas un synonyme de "validation" ? Et que les tests sont le principal outil de validation du bon fonctionnement ?
3  2 
Avatar de Dgamax
Membre averti https://www.developpez.com
Le 11/02/2019 à 11:15
Citation Envoyé par SimonDecoline Voir le message
Heu... on parle d'un plugin wordpress là. Il y a vraiment des sites à gros trafic qui sont fait avec wp + des plugins ?
Il existe beaucoup de site, plus ou moins gros, qui sont gérés par Wordpress.

Quelques exemples :
jquery.com, plesk.com, dyn.com, nginx.com, etc...
https://kinsta.com/blog/wordpress-site-examples/

Wordpress représente 33% des sites internet.
1  0