Attention, ce post est ultra-geek.
J’ai quelque peu fait allusion précédemment à ce langage un peu exotique. Il faut dire que mon côté geek aime bien tout ce qui est langages de programmations. J’ai très tôt apprécié Ruby et Rails, et l’approche agréable du «tout objet» de Ruby.
Mais l’aventure YesOrNow version 1, entièrement en Rails + JS, il m’est apparu des choses toutes bêtes, et j’ai cherché comment y remédier.
Ces «choses toute bêtes» sont à mon sens des facteurs clef de succès dans le web. Car c’est un chose d’avoir une bonne proposition de valeur, un bon marketing mix, une bonne interface. Il faut que derrière, cela tienne, et que cela soit performant.
L’approche Rails / 37 Signals / désinvolte, c’est en deux mots : si vous avez des problèmes de scaling, cool, c’est que ça cartonne ! En effet, mais autant ne pas avoir de problème de scaling, car préserver l’expérience en cas de forte exposition est justement primordiale : c’est tout d’un coup l’occasion de faire connaître ce que l’on fait à de nombreuses personnes… autant que la première impression soit bonne.
Aussi, pour 37 Signals, leur business model uniquement par abonnement, sans partage entre comptes clients, limite ces problème de scalabilité car le coût a moins à jouer.
L’argument, c’est aussi qu’une architecture scalable, c’est complexe. Cela veut dire systèmes de cache (mais cela, même quand on a pas à scaler, c’est nécessaire car améliore immensément les performances et soulage le server…. d’autant que NGinx l’intègre dans son coeur), systèmes genre memcached de distribution, cache et partage d’objets, réplication de bases MySql et structures Master-Slaves ou autre… Enfin, tout le tintouin.
PHP n’est pas bien différent. La seule différence avec PHP, c’est que ce language est tellement souple qu’il est un peu trop facile de mal coder… Et comme tous les développeurs web font du PHP, il est plus difficile de séparer le bon grain du mauvais grain.
Et donc… Erlang.
Erlang, c’est d’abord un monsieur, un mathématicien. Mais ça on s’en moque.
Erlang, c’est maintenant un language. Un truc un peu fou inventé chez Ericsson pour leurs besoins propres, afin d’avoir des PABX et autres machineries des telecoms qui soit stables, performantes, etc… Enfin, un truc pour gérer des telecoms au niveau d’un pays quoi.
Donc, quelques mecs se sont réunis, dont un certain Joe Armstrong, qui est un peu le DHH d’Erlang, version père de famille, je fais pas de surf des neiges, mais je suis brillant et marrant, et ont réfléchi.
Ils ont pondu Erlang, qui est un langage fonctionnel.
Pour ceux qui se demandent, un langage fonctionnel c’est ça (Wikipedia) :
La programmation fonctionnelle est un paradigme de programmation qui considère le calcul en tant qu’évaluation de fonctions mathématiques et rejette le changement d’état et la mutation des données. Elle souligne l’application des fonctions, contrairement au modèle de programmation impérative qui met en avant les changements d’état.
En gros, ici, pas d’objet, des fonctions. Que des fonctions, dans des modules. On ne partage aucune donnée, on se passe des messages entre fonctions. Moi, personnellement, ça me plaisait bien, parce que je codais intuitivement un peu comme cela : la programmation objet me faisait mal à la tête, car je savais jamais où en était mes objets à chaque moment. Là je sais.
Après, Erlang a d’autres caractéristiques, qui elles sont intéressantes pour nous, personnes du Web.
1. C’est un langage concurrent. C’est à dire que les process fonctionnent en même temps en utilisant toutes les ressources des processeurs multicoeurs. Cela est possible car la mémoire n’est pas partagée : les fonctions s’envoient des messages. Mais là où ça devient génial, c’est qu’Erlang fonctionne par noeuds : c’est à dire que ma fonction trucmuche, sur mon Mac, peut envoyer un message à la fonction bidule sur le PC de mon pote australien, qui à son tour envoie un message à machin etc… Scalabilité vous avez dit ?
2. C’est un langage rapide, qui se compile à la volée. En gros, plus de deux fois plus rapide que PHP5 et 4 fois plus rapide que Ruby.
3. C’est un langage qui supporte nativement le versionning. C’est à dire qu’on peut faire une rollout de nouvelles fonctionnalités ou corriger des bugs sans downtime, le language intègrera de lui même les nouvelles versions intelligemment.
4. C’est un langage qui incorpore sa base de donnée, Mnesia, elle même distribuée sur plusieurs noeuds, on peut fragmenter les tables, etc… et les performances sont excellentes.
5. Plusieurs serveurs web existent pour Erlang : Yaws, Mochiweb principalement. Les deux ont des performances superbes, surtout derrière un Nginx. Yaws est célèbre pour tenir à plus de 80 000 connexions simultanées quand Apache meurt à 4000….
6. Quelques frameworks web commencent à poindre leur nez, dont Nitrogen. Et aussi, niveau CMS, Zotonic apparaît. Au programme,… je vous laisse découvrir.
7. Dernier point : la possibilité de bundler son applicatif, erlang compris. Vous l’uploader sur le serveur, vous configurer votre NGinx pour qu’il pointe sur le bon port de votre mochiweb, vous faites un petit ./start.sh, et hop, c’est live, database incluse. C’est pas beau ça ?
Sinon, niveau syntaxe, au début, ça surprend…. Surtout quand on sait qu’une variable ne peut changer de valeur… mais son scope est limité à sa fonction. En fait, il faut vraiment plonger dedans pour comprendre (je commence à peine) comment ça marche, mais ça va assez vite.
En fait, ce qui me plaît dans ce langage, c’est qu’il semble résoudre la plupart des contraintes techniques du Web : performance, stabilité, scalabilité.
Petit détail en passant : 37 Signals, Facebook et Meetic utilisent Erlang pour leurs systèmes de chat.
Et bien sûr, le gros inconvénient d’Erlang c’est de trouver des développeurs en Erlang !
Donc voilà, c’était le post ultra-geek pour commencer février. Promis, je ne parlerai pas d’Haskell ni d’OCaml !
Mots-clefs : Erlang, Programmation, Web
Je ne comprends rien, mais nice picture!
@Lucas : merci pour le comment sur la photo, c’est le mont Fuji, une photo que j’ai prise lorsque j’étais au Japon avec HEC.
Moi non plus j’y comprend pas grand chose, a vrai dire, mais je vais forwarder ça a un type avec qui j’ai taffé sur une start-up a New York et qui est tellement apôtre de 37 signals et de Ruby on Rails qu’il pomperait son fondateur. Malheureusement, ça n’a fait que ralentir la start-up.
Intéressant. Un peu comme un réseau neuronal, mais où chaque neurone serait une fonction de transformation ?
Ou un peu comme un circuit électronique finalement, où chaque composant a un (ou plusieurs) flux en entrée et un (ou plusieurs) flux en sortie ?
En tout cas je vais m’y pencher de plus près, au moins pour l’aspect conceptuel.
[HS G33K MODE]
Moi je suis très orienté objet en ce moment : Objective C et iPhone SDK. Ce n’est pas si compliqué que ça, mais il faut s’y plonger sérieusement. Je suis les cours de Stanford sur iTunes U. La syntaxe est sérieuse, mais très rigoureuse donc répétitive, donc mémorisable.
En tout cas c’est brillant, et assez passionnant. J’ai plein d’idées, et peut-être une appli dans quelques semaines (malgré 140 000 applications, il y a encore des lacunes sur l’AppStore…) ;)
[/HS G33K MODE]
Après une visite sur Zotonic :
Oui ce cms est très séduisant, mais la question de mise à l’échelle (scalability) mise à part, on retrouve les mêmes inconvénients qu’avec Rails, à savoir :
- La difficulté de trouver des hébergeurs compatibles (dis-moi si je me trompe)
- La difficulté de trouver des développeurs initiés au langage pour assurer la pérennité du système mis en place (argument souvent factice – quand je suis prestataire sur un projet, ce n’est pas pour le refiler au premier dev venu -, mais qui donne beaucoup de poids à des solutions génériques comme wordpress ou même – hélas – joomla, ou encore simplement le couple php/mysql)
Pour un projet personnel ou artisanal pourquoi pas (enfin faut voir le coût/la complexité de l’hébergement), mais pour un projet industriel, il faut voir : mêmes les PME préfèrent parfois un bulldozer à une tapette pour écraser une mouche.
Aussi, dans un espace libre de contrainte, en effet, Zotonic l’emporte haut la main dans bien des cas, mais le monde économique étant pétri de contraintes, des solutions plus installées (et donc plus vétustes) seront sinon préférables, préférées…
Désolé de prendre ton post comme support éditorial, mais tu touches un point vraiment intéressant auquel je suis souvent confronté : il y a moins d’une semaine, j’ai dû utiliser limesurvey (un monstre opensource du questionnaire) pour faire un petit sondage que j’avais initialement programmé en php/jquery avec génération des questions à la volée sans bdd. Ma solution était très élégantes et répondait au besoin de manière chirurgicale, mais n’était pas assez ‘industrielle’. J’ai dû me rabattre sur la solution générique, peu adaptée, archaïque, mais qui a fait ses preuves, et pourtant je travaillais pour une startup.
Je détourne vraiment ton post à mon compte, mais si toi ou un lecteur veut poursuivre le débat, je suis avide de retours d’expérience, et serais très heureux de partager sur le sujet.
Je me soumets à ton pouvoir de modération ;)
Tu touches en effet à un point crucial, qu’on pourrait appeler « conservatisme technologique » ?
Au niveau de l’hébergement, je suis à peu près d’accord… A part que :
On peut héberger ses sites sur du mutualisé ovh ou amen, donc sur du prepackagé, prémaché, préinstallé, c’est sympa, mais les minutes que l’on gagne à la mise en place, on fait plus que les perdre après… Même certains trucs en PHP ne passent pas, en fonction des configurations, etc… car même en PHP (voire même surtout), tu te retrouves facilement pour certains trucs à devoir gérer pléthore de dépendances pour faire fonctionner ton site.
Je suis plus partisan pour du VPS ou du dédié, sur un hebergeur sérieux, qui te laisse carte blanche pour ta config.
Après, aussi, le target de ce post est plus sur des systèmes un peu balèzes. Zotonic je pense a une vraie valeur ajoutée par ses performances et sa modularité, et donc sur des projets a haut traffic. Je vois Zotonic un peu dans la même cour que Drupal, et donc sur des sites de cette complexité.
Sinon, au niveau déploiement, j’y fais référence dans mon post, je suis plus que surpris de la facilité de déploiement des applis Erlang. Ruby me paraît une atrocité à côté. Tu peux même pour plus de souplesse t’amuser à packager ton appli en intégrant Erlang dedans et ses dépendances, du coup, tu n’as plus aucun problème. Tu copies ton application, tu fais un bon vieux make, puis tu la lances avec start.sh un fois ton NGinx configuré vers le port de ton appli.
Du coup tout ce dont tu as besoin, c’est d’une bécane avec NGinx (ça pourrait marcher avec Apache je pense, mais ses fichiers de configuration sont un peu plus atroces et ses perfs moins bonnes). Et même, je crois que tu pourrais te passer de NGinx ! :D (faudrait que je teste ;) )
Mais voilà, après, on est toujours confronté à
1 // Le conservatisme technologique. Les personnes connaissent quelque noms : PHP, Joomla, Drupal… et dans d’autre structures, JAVA ! (je me rappelle d’une discussion avec Arnaud de Typhon, où on se tatait pour l’installation d’un moyen de paiement, et le frein avait été l’installation de la plateforme Java, avec TomCat et tout le tutim…).
2 // Le marché de l’emploi. Trouver des programmeurs dans des langages un peu exotiques est une galère… mais je t’avoue que de plus en plus, j’ai envie d’avoir la main sur le dev, pouvoir initier les choses, prendre le relais, en tout cas savoir et comprendre comment est architecturé réellement les produits sur lesquels je transpire pour pouvoir prendre le relais. Et aussi, un programmeur qui s’intéresse à des problématiques un peu pointues, ça veut dire qu’il se pose des questions pertinentes et a une démarche plus fouillée et pointue. Donc le langage est aussi un moyen de sélectionner des compétences.
Après, un petit PHP pour faire du petit script rapide, c’est efficace, rapide, et à mon sens ça correspond au scope initial de PHP. Faire une landing page rapidement, un petit formulaire, c’est pratique. Exactement ce que tu as fait pour ton questionnaire à la base donc.
Le seul problème de PHP à mon sens, c’est que ce n’est pas balisé, et on peut trop rapidement soit faire une usine à gaz en objet totalement abstraite, soit quelque chose de très brouillon, soit les deux en même temps.
En même temps, tout le front end de FB est en PHP (même s’il viennent de sortir un compiler PHP -> C++, ce qui pourrait se révéler très intéressant pour de la perf).
Enfin,ça va commencer à ressembler à du troll de dev, donc j’arrête là.