Quels langages pour ce développement?

[bohwaz]

@sekil

En l’occurrence, outre le fait que PHP soit très mal adapté pour implémenter un serveur ou un démon de manière générale (les dev Nextcloud se débattent avec memcache, redis &cie pour pallier leur erreur initiale)

Je répond juste à ça pour le moment : c’est faux. PHP est très performant. En conditions équivalentes (mode asynchrone avec Swoole par exemple) il est 30% plus rapide que NodeJS et équivalent à Go.

J’ai bossé sur l’ex plus gros réseau social européen, avec des dizaines de millions d’utilisateurs, et notre code était en PHP, avec quelques dizaines de serveurs seulement : PHP fait très bien le taf en conditions réelles

NextCloud n’a pas fait l’erreur d’utiliser PHP, mais l’erreur de développer en accumulant les fonctionnalités sans jamais remettre à plat leur code, qui est un véritable plat de spaghetti. Les perfs de NextCloud sont effroyables non pas à cause du langage mais du style de développement, et de l’absence totale d’objectifs d’efficacité dans leur mode de développement. Sur les même fonctionnalités que NextCloud (gestion de fichiers), Paheko est 13 fois plus rapide et sert 41 fois plus de requêtes simultanées, et je ne suis même pas hyper attentif aux perfs quand je code ^^

Enfin, NextCloud n’est pas un daemon donc pas trop de rapport.

Fin du HS

[sekil]

Attention, je ne cherche pas à basher PHP, d’autant que ça reste un de mes langages de prédilection, je dis juste que chaque langage a son(es) usages(s). Tout le monde dit que PHP8 a grandement amélioré les performances, je n’ai pas eu l’occasion de faire une comparaison donc je leur fait confiance sur ce point. Tu remarqueras donc que je n’ai jamais parlé de performances.

PHP est un langage adapté à des usages stateless pour répondre à des requêtes HTTP (on l’intègre très souvent en CGI/FastCGI/FPM, plus rarement en CLI) :

• Je reçois une requête HTTP
• L’agent PHP (CGI/FPM) reconstruit le contexte à partir des cookies et des sessions, si nécessaire avec une BDD ou un cache mémoire
• Il doit traiter la requête en moins de 30 secondes, et idéalement en quelques dizaines de ms
• Il renvoie la requête et supprime le contexte

Si j’ai cité Nextcloud, c’est qu’il y a de très nombreuses features d’un cas d’usage gestion de fichiers qui ne marche pas en stateless :

• Faire des opérations de nettoyage en tâche de fond, tu dois configurer un cron ou un webcron pour le faire, parce qu’il n’y a pas de service en tâche de fond.
• Renvoyer un fichier de plusieurs Go en WebDAV, Nextcloud est logiquement obligé de le diviser en chunks et ne peut pas nativement garder un contexte (notamment un descripteur de fichier ouvert).
• Monitorer des modifications sur des fichiers
• Gérer des timeout sur des partages supérieurs à 30 secondes (j’ai eu le cas sur des partages FTP)

Ce type d’opérations, même si elles sont pour la plupart basées sur des requêtes HTTP, requièrent l’exécution d’un démon.

Bien entendu, tu peux exécuter PHP via PHP-CLI et spawner des threads pour répondre aux requêtes ou faire toute opération arbitraire, mais je maintiens que PHP n’a pas été fait pour ça. De la même manière, je ne coderais pas un site Web en C, même si j’aime beaucoup le C et que je sais que c’est possible.

En bref :

• PHP est super pour répondre à de très nombreuses requêtes simples et/ou nécessitant un contexte limité
• PHP n’est pas adapté pour répondre à un faible nombre de requêtes très complexes et nécessitant le maintien d’un contexte ou une interaction système

[bohwaz]

PHP a un usage stateless par défaut dans les serveurs web, mais c’est pas du tout obligé.

PHP dispose d’excellents modules permettant d’intégrer le serveur web, via Swoole ou ReactPHP par exemple. Dans ce cas c’est ton appli qui gère le serveur HTTP, et donc tu peux avoir des descripteurs ouverts et partagés entre les requêtes. La même chose qu’en NodeJS par exemple. Mais c’est un genre de programmation très différent, et ça ne fonctionne pas en mutualisé. C’est bien quand tu as un serveur dédié, mais là où PHP excelle c’est de pouvoir héberger des milliers d’applis différentes sur le même serveur.

NextCloud fait des chunks non pas parce qu’il ne peut pas garder un contexte, mais parce que les transferts venant des clients peuvent échouer, et donc c’est plus simple de recommencer l’upload d’un chunk de 10 Mo que d’un fichier de 2 Go. Ça n’a rien à voir, c’est une bonne pratique pour gérer les connexions instables.

PHP sait aussi très bien faire des timeouts de plus de 30 secondes, j’ai déjà testé avec succès l’envoi de fichier sur Paheko sur une connexion EDGE, en plus de 2 heures ça roule

Je ne suis pas d’accord, PHP est très bien adapté aussi à maintenir un contexte, c’est juste que tu n’utilise pas les mêmes outils c’est tout. J’ai déjà codé des daemons en PHP (sans Swoole ni ReactPHP), ça marche très bien

[ppom]

C’est vrai qu’aujourd’hui PHP est orienté objet, modulaire, performant. C’est le cas de plein de langages de programmation.
Outre que le langage en lui-même, je pense que c’est intéressant de se pencher sur l’écosystème autour du langage : pour quoi il est majoritairement utilisé (et donc pour quoi on trouvera de l’aide en ligne), et quel écosystème de librairies existent.
Quand viendra le moment, il sera sûrement pertinent de faire une liste de voeux pour les librairies voulues (smtp, queues, bdd, etc, je sais pas), et de chercher un langage qui a des librairies propres et bien maintenues pour notre cas d’usage.

[bohwaz]

Perso j’aurais bien vu du Go mais j’y connais pas grand chose à part quelques bidouilles, et j’aime pas du tout la dépendance à Google.

L’avantage de PHP que j’aime bien, c’est le fait que la standard library (les fonctionnalités de base) sont très étendues, et contrairement à Rust/Go par exemple, y’a pas besoin d’installer des dizaines (/centaines) de dépendances, dont on ne connaît pas le code, qui exposent à des soucis de sécurité potentiels, juste pour faire des trucs basiques (genre du chiffrement, du base64, etc.).

Par exemple pour le chiffrement, libsodium est intégré à PHP en standard, le binding est maintenu par l’auteur de libsodium, et c’est donc packagé aussi sur Debian. Sur Go, c’est une lib gérée par un inconnu, qui est téléchargée pour chaque personne (non packagé debian). Il me semble plus difficile de compromettre la première solution, que la seconde.

C’est un exemple, mais perso moins j’ai de code à auditer, mieux je me porte Et oui parce que je lis et essaye de comprendre le code de tout ce qui n’est pas packagé par Debian, avant de l’intégrer à un projet. Du coup quand je fait un « composer install » et que le répertoire « vendor » fait 200 Mo, heu ben je vais voir ailleurs

Après je pense au fond que la question n’est pas trop le langage, que la spécification du logiciel : ce qu’il doit faire et comment. Par exemple si on spécifique le logiciel doit être léger en ressources, et avoir le moins de dépendances possible, une API simple et lisible, d’avoir une interface web sans librairie javascript type react, mais au maximum en natif JS, etc. ben le langage derrière importe peu, c’est plutôt la logique qui compte.

Et pour moi à partir du moment où on spécifie une API de communication entre relais (et aussi une API pour les logs, les stats, etc. d’un point de vue admin/utilisateur) qui soit claire, simple et interopérable, on s’en fiche un peu du langage car il pourra y avoir une autre implémentation compatible théoriquement

[bohwaz]

Je découvre par pur hasard la librairie Perl « Sisimai » qui permet de parser les bounces : https://github.com/sisimai/p5-sisimai

Ça reconnaît pas mal de cas de figures, comme décrit ici : https://libsisimai.org/en/reason/

Et pas mal de providers, notamment exemple ici pour Laposte.net/Orange.fr : https://github.com/sisimai/p5-sisimai/blob/5-stable/lib/Sisimai/Rhost/FrancePTT.pm

Ça sort du JSON, donc possible de l’exécuter sur un message et récupérer le JSON pour un autre outil dans un autre langage.

[n-peugnet]

@bohwaz

L’avantage de PHP que j’aime bien, c’est le fait que la standard library (les fonctionnalités de base) sont très étendues, et contrairement à Rust/Go par exemple, y’a pas besoin d’installer des dizaines (/centaines) de dépendances, dont on ne connaît pas le code, qui exposent à des soucis de sécurité potentiels, juste pour faire des trucs basiques (genre du chiffrement, du base64, etc.).

J’aime beaucoup PHP aussi, mais quand-même en terme de lib standard je le mettrais vraiment pas au dessus de Go. J’ai rarement vu une lib standard aussi large et flexible que celle de Go, pour une bonne partie des projets c’est dèjà suffisant pour commencer, je pense aussi à tous les outils qui vont autour. Parce que pour les tests unitaires en PHP tu as par exemple besoin de PHPUnit (ou autre mais je connais pas), qui d’ailleurs, passe son temps à déprécier et supprimer des fonctionnalités au fil des versions. Et c’est là pour moi que Go est très intéressant, avec son attachement à faire perdurer les interfaces existantes et à ne pas casser le code des gens d’une version à l’autre.

@bohwaz

Par exemple pour le chiffrement, libsodium est intégré à PHP en standard, le binding est maintenu par l’auteur de libsodium, et c’est donc packagé aussi sur Debian. Sur Go, c’est une lib gérée par un inconnu, qui est téléchargée pour chaque personne (non packagé debian). Il me semble plus difficile de compromettre la première solution, que la seconde.

Je ne me rends pas compte ce qu’apporte libsodium par rapport au paquet crypto de la stdlib de Go ? crypto package - crypto - Go Packages

Après en vrai vous faites ce que vous voulez haha, j’ai juste tiqué sur l’argument de la lib standard. PHP avec les typehints et PHPStan c’est quasi aussi confort qu’un langage avec du typage statique.