Pour continuer sur la lancée de mon précédent article intitulé “Ruby vs Python ?”, qui, il faut bien le dire a mis la blogosphère à feu et à sang (hier encore je discutais avec les Daft Punk des bienfaits de method_missing), je vais m’intéresser aujourd’hui au langage Erlang.

On pourra dire ce qu’on voudra de Ruby on Rails, je constate que cette technologie a au moins un mérite : faire bouger les lignes, les gens, les idées (un peu comme l’iPhone et le monde de la téléphonie mobile). Du coup, après quelques années de vaches maigres intellectuelles, nos cerveaux se sont remis en route. Ainsi, on s’est souvenu qu’il faut constamment se renouveler, se mettre à jour, bref, être en veille permanente, si on ne veut pas rester bloqué aux tourniquets pendant que le métro quitte le quai.

D’un côté, on a toujours une partie de la population des développeurs web qui s’attache à rafraîchir les technologies qu’ils utilisaient avant l’apparition de Ruby on Rails. C’est ainsi que l’on a vu l’émergence des frameworks CakePHP ou Symfony dans le monde PHP, Grails dans le monde Java ou encore Turbogears dans le monde Python (1). Django a une place un peu spécial dans cette aventure : comme Rails, cette techno est extraite d’un projet client (2), et, elle est née du besoin de revoir la façon dont on a développé des applications web les années précédentes.

De l’autre, on a les gens qui, sur la lancé de Rails, continuent la quête perpétuelle du bonheur absolu. Tout d’abord, ces gens sont arrivés à Rails. Ils se sont dit que c’était une bonne techno (3) pour développer des applications web, c’est-à-dire un bon outil pour le développeur. Mais qu’en est-il de l’administrateur qui va gérer l’application en production ? Qu’en est-il des performances ? Qu’en est-il de la facilité de déploiement ? Parti de ces constatations, c’est toute la “stack”, toute la pile des technologies nécessaires à faire tourner une application web qui se sont vues scrutées, analysées et décortiquées. Et c’est ainsi qu’on a pu voir apparaître quelques étoiles au firmament (certaines éphémères) comme LigHTTPD, Lightspeed, Capistrano (3), Mongrel, Nginx (4).
Au-delà de la technologie, c’est une réflexion globale qui a été mené sur la façon de développer des applications web, en industrialisant le processus (en introduisant ou en rafraîchissant le concept de chaîne de production), sur la façon quasi philosophique de gérer le développement (“Less Code”) ou sur la façon de gérer un projet (“Getting Real” en est un pilier).

C’est dans ce cadre évolutif constant que l’on entend de plus en plus parler du langage Erlang. Erlang est un langage fonctionnel concurrent temps réel et distribué, qui possède des fonctionnalités de tolérance aux pannes, et de mise à jour du code en temps réel pour des applications à haute disponibilité (cf Erlang).
Et on entend souvent la question suivante : est-ce que les wizz kids se tournent actuellement vers Erlang parce que Ruby est devenu trop mainstream ? Est-ce que Erlang est la prochaine étape ?
D’après moi, ce qui fait la force de Rails et de Ruby, c’est une très bonne accessibilité (on arrive facilement à lire du code Ruby, même si vous ne connaissez pas ce langage), le fait que l’on puisse programmer avec plusieurs styles différents (impératif, objet et même fonctionnel).
Or, Erlang, malgré ses qualités intrinsèques, impose une syntaxe difficile à appréhender et un changement de paradigme (passage à de la programmation fonctionnelle). Je pense donc qu’Erlang va surtout trouver sa place sur certaines niches, mais sa popularité ne pourra sans doute jamais atteindre celle de Ruby et Rails ou même celle de Python. D’autant plus que l’on connait surtout le monde Ruby par la loupe Ruby on Rails alors que le monde Ruby en lui-même en a encore beaucoup sous le pied…

Conclusion

Mes cours de Caml seront sans doute utiles pour programmer en Erlang ! Voilà un point positif. Pour certaines problématiques bien précises, Erlang semble être bien plus prometteur que Ruby et les deux technos sont sans nul doute complémentaire et ilest fort probable que cette complémentarité amène des groupes de gens différents à collaborer. D’un autre côté, EventMachine avance à grand pas…

PS : “1 idée par mois” est de retour. Stay tuned.

(1) évidemment, tous ces gens vous diront que Rails ça ne sert à rien, que leur truc est mieux, alors qu’en réalité ils copient surtout ce que propose Rails
(2) je constate que les projets qui sont extraits d’une application existante, c’est-à-dire né d’une problématique claire et identifiée, sont beaucoup plus accessible pour les développeurs qui ne faisaient pas forcément partie de la problématique de départ
(3) je rappelle que “Capistrano et le cycle de vie des applications Rails” est toujours dispo 🙂
(4) pour info, toutes mes applications web tournent avec Mongrel et Nginx et sont déployées grâce à Capistrano