Prologue

Ce billet n’est pas un article d’introduction à Elixir. C’est juste un billet dans lequel je partage mon expérience et mon ressenti, sur un travail de veille sur Elixir cet été. Ce billet est également l’occasion de prendre du recul sur l’apprentissage de technologies qui peuvent être considérées comme exotique par rapport aux technologies que l’on utilise plus couramment en entreprise.

A la recherche de la pierre philosophale

J’ai profité de l’été et des périodes de congés qui allaient avec pour regarder un peu le langage Elixir. Cela fait un moment que je souhaitais regarder de plus près le langage et la plateforme.

Au quotidien je fais essentiellement du développement Java avec Spring mais cela fait un moment que j’essaie d’ajouter à ma trousse à outils un style de programmation plus fonctionnelle. A cette fin j’ai déjà essayé des langages sur la JVM comme Scala et Clojure (avec une nette préférence pour Clojure mais j’ai toujours eu une certaine partialité envers les LISP) et bien sûr avec l’arrivée de l’API Stream en Java, je peux aussi avoir un style plus fonctionnel au quotidien. En me mettant à Elixir, je voulais ainsi continuer à progresser sur le plan de la programmation fonctionnelle mais également explorer une plateforme qui donne une place centrale aux systèmes distribués (et pas seulement à la concurrence) au niveau du langage.

En effet, dans mes dernières missions, au quotidien je travaille sur des projets mettant en oeuvre des microservices développés en Java, donc in fine sur des systèmes distribués mais sans forcèment avoir les bons réflexes et les bonnes questions par rapport à la distribution.

Mon objectif était donc double : découvrir un autre langage fonctionnelle pour m’améliorer sur le style de programmation fonctionnelle et découvrir une philosophie de conception et de programmation qui met l’accent sur la distribution des traitements.

La quête

Pour organiser cette exploration d’Elixir en fonction des contraintes qu’il était les miennes (par exemple accès à Internet limité et pas forcément la possibilité de passer beaucoup de temps devant un ordinateur), je me suis appuyé sur des livres et des podcasts.

J’ai lu 2 livres :

  • Elixir Succintly de Emanuele DelBono : fidèle à l’esprit de cette collection de livres électroniques gratuits, c’est une présentation rapide (sur environ 80 pages) du langage et de la plateforme, cela permet de se faire rapidement une idée. Mon objectif en lisant ce livre était de voir si cela me donnait envie d’investiguer plus profondément.
  • Programming Elixir de Dave Thomas : le livre ne se veut pas une présentation exhaustive du langage mais en fait un tour quand même assez complet avec beaucoup de pédagogie. J’ai vraiment apprécié la lecture et cela m’a donné envie de lire la nouvelle édition de The Pragmatic Programmer

Je me suis abonné à différents podcasts traitant d’Elixir et de son écosystème :

Pour l’instant, j’ai surtout écouté des épisodes de Elixir Wizards Podcast et de Elixir Mix. De ces épisodes écoutés, j’en ai particulièrement apprécié un dans lequel Dave Thomas était interviewé.

Côté pratique, j’ai mis à profit la track Elixir de Exercism et les exercices proposés dans Programming Elixir mais à ce stade très clairement pas assez …. mais bon on fait comme on peu.

Je suis aussi aller faire un tour sur Elixir School et j’en ai profité pour contribuer modestement à la traduction française (une manière comme une autre de contribuer à des projets open source).

There and back again

Je cherchais du dépaysement zt j’ai été servi : Elixir cela fait quand même un choc culturel quand on pratique Java au quotidien. Certes, je connais Ruby (la syntaxe d’Elixir est inspirée de Ruby même si a bien des égards Elixir n’a rien à voir avec Ruby), comme écrit plus haut, j’ai déjà un peu essayé des langages fonctionnels et je ne suis pas réfractaire à un style de programmation fonctionnelle bien au contraire, mais j’ai appris des choses et cela m’a amené à réfléchir. Cela tombe bien c’était l’un des objectifs !

Je ne vais pas énumerer si après toutes les spécifités et caractéristiques d’Elixir. Comme indiqué plus haut, ce n’est pas un tutoriel, c’est plus un compte-rendu d’expérience, je me focalise donc sur ce qui m’a marqué.

Tout d’abord il y a le pattern matching (la traduction française serait filtrage par motif). Certes, cela existe dans d’autres langages et c’est en train d’arriver en Java par exemple, et j’en avais utilisé quand j’avais fait du Scala.

Cependant, là ce n’est pas juste du pattern matching à travers un case mais carrèment au niveau des fonctions. Ainsi vous pouvez définir de multiple clauses à une même fonction, chaque clause correspondant à une branche de votre match. Du coup, votre besoin en structures de contrôle conditionnelles est limité : vous pouvez écrire des programmes dans lequel vous n’aurez pas de if/else ou équivalent. Cela amène à voir et à penser les choses différemment.

Ensuite, bien sûr, il y a l’opérateur pipe (|>) qui permet de visualiser concrètement le flux de données d’une fonction à une autre. Dans des langages comme Elixir, on est sur une approche Data Oriented Programming et cela demande un changement de mindset par rapport à une approche objet classique. Là aussi cela amène à voir et à penser les choses différemment même si pour le compte c’est quelque chose que j’avais déjà pratiqué en Clojure et qu’au final on peut faire avec l’API Stream de Java. Ce qui est intéressant ici c’est aussi la lisibilité que l’opérateur pipe apporte.

Cependant la vraie claque, c’est quand vous abordez la programmation distribuée avec Elixir et la VM Erlang. Je croyais à tord qu’Elixir (et Erlang) proposaient un modèle de concurrence intégrée au langage basée sur le modèle d’acteurs au même titre que le langage Go propose (entre autre) un modèle de concurrence basée sur les CSP : ce n’est pas juste un modèle de concurrence, on est sur un modèle pour développer des systèmes distribués au niveau du langage et de la VM. J’ai même l’impression que vous n’avez pas trop le choix dès que vous developpez en Elixir/Erlang, vous développez un système distribué.

NB : ne pas voir ci-dessus une critique du langage Go, on est sur des cas d’utilisation différents et je souligne juste une erreur d’interprétation de ma part.

Quand on développe une application sous forme d’un ensemble de micro-services, on développe un système distribué. Chaque micro-service est une application indépendante proposant un ensemble de fonctionnalités cohérentes et limitées. L’ensemble de ces micro-services une fois déployées vont interagir par échange de messages pour former notre système distribué qui répond à un besoin métier.

L’essence de la programmation avec Erlang et Elixir, c’est de faire la même chose mais à l’échelle du dessous : des modules regroupant un ensemble de fonctions sont des processus indépendants qui interagissent par échange de message pour répondre au besoin métier. Si on transposait dans l’univers Java ou C#, cela serait des instances de classes qui interagiraient par échange de messages (pas par appel de méthode d’une classe dans une autre) directement. Et tous les outils pour assurer la supersivion de ces processus sont présents. De plus, ces processus pourraient être déployés sur des VM sur plusieurs noeuds distincts (pouvant correspondre à des machines physiques différentes) et continuer à communiquer de manière transparente.

La programmation distribuée est la partie que j’ai trouvé la plus impressionnante et qui - à mon sens - représente le véritable intérêt d’Elixir mais également la véritable difficulté pour l’apprendre. Je ne dis pas qu’il soit trivial de se faire à une approche fonctionnelle quand on n’y est pas habitué. Cependant organiser son code comme un ensemble de composants distribués et gérer toutes les subtilités de la philosophie Let it crash et des outils qui vous permettent de garder votre système fiable, ce n’est pas simple et cela demande de la pratique. Au passage, les mécanismes de déploiement à chaud sont également assez impressionnant et bien pensé. On sent bien derrière Elixir le poids de l’expérience et du savoir faire développés avec Erlang.

Retour à la maison

Pour l’instant, je suis resté très en surface d’Elixir et de son écosystème. De nombreuses heures de pratique me séparent d’écrire du code idiomatique en Elixir et de l’utiliser de manière pertinente. Surtout que pour maitriser réellement Elixir, cela demande quand même d’avoir une certaine compréhension de la VM Erlang. Et puis cela suppose aussi de se familiariser avec son écosystème et des projets emblématiques de ce dernier, comme par exemple Phoenix ou Nerves.

En bref Elixir ne s’apprend pas en un week-end et il faut avoir le cas d’utilisation : si c’est juste pour faire mumuse sur Exercism et sur des petits programmes quand on a le temps le week-end, on peut clairement se demander si cela vaut le coût d’investir du temps (qui pourrait être employé à quelque chose d’autre) même si intellectuellement cela sera un chemin intéressant.

De plus de manière lucide, Elixir ce n’est pas une technologie que l’on peut (raisonnablement conseiller d’) introduire en douce ou sans qu’il y ait un véritable besoin et une volonté forte de l’utiliser au niveau des développeurs. Et des missions Elixir/Erlang en France on n’en trouve pas beaucoup.

Alors quel intérêt ? Et bien cela va dépendre de vos objectifs.

Si vous voulez voir une manière différente de concevoir et de coder que celle à laquelle vous êtes habitués dans des approches impératives ou objet pour changer votre perspective sur votre manière de coder, Elixir est un bon choix. Clairement cela est dépaysant et très enrichissant intellectuellement pour qui ne connait pas la programmation fonctionnelle et/ou distribuée.

Si vous avez un besoin spécifique en développement Web ou en système embarqué, il pourra être intéressant de regarder respectivement si Phoenix ou Nerves répondent à votre cas d’utilisation.

Si vous avez besoin de développer une application qui doit avoir un très haut taux de disponibilité ou être distribuée, Elixir peut clairement être une option à étudier.

Maintenant, je doute qu’on puisse recommander d’appendre Elixir pour trouver plus facilement une mission, un emploi ou améliorer son employabilité. Apprendre Elixir vous rendra très certainement un meilleur développeur mais cela sera difficile à vendre sur un CV ou dans un entretien, et d’autant plus qu’Elixir ou Erlang sont assez peu connus.

L’apprentissage d’Elixir est très enrichissant mais il demande investissement et motivation.

Epilogue

De mon côté, je trouve Elixir très intéressant et je souhaiterais approfondir en mettant plus en pratique et en essayant Phoenix. Cependant, je sais que l’investissement en temps est important, avec un temps à allouer pour la veille qui est hélas réduit. Je n’ai pas la possibilité d’en faire réellement dans le cadre de ma mission, sur laquelle je dois enchaîner les projets à faire dans l’urgence. Pourtant je travaille dans une ESN, Norsys, qui m’alloue du temps pour faire de la veille technologique, mais par rapport à ma mission actuelle, je n’ai tout simplement pas la possibilité de profiter de cette allocation de temps pour faire de la veille active.

Les exigences des projets dans le cadre professionnel font que dans un compromis intérêt/utilité directe, j’utilise une partie de mon temps personnel dédié à la veille pour me former à des technologies que j’estime ne pas maitriser suffisamment dans le cadre de mon activité professionnelle.

Enfin, maintenant que mon fils (jeune collégien), exprime depuis peu un intérêt pour la programmation (qui a dit que les jeux vidéos cela n’amenait rien de bon ?), je priorise par rapport à ma veille de lui apprendre les bases de l’informatique et du codage. Et Python m’a semblé un choix plus pertinent qu’Elixir pour cela (surtout avec mon niveau de maitrise d’Elixir actuel).

Pour l’instant, c’est une activité au ralenti : je continue en pointillé à explorer Elixir dès que j’ai un peu de temps avec Exercism et les traductions en français des leçons de Elixir School, en attendant de pouvoir y consacrer plus de temps ou de finir par décider que l’approfondissement d’Elixir ne doit plus être une partie du portefeuille de connaissances que j’essaie de maintenir.