Erlang, Elixir, OTP, BEAM, concurrence

Xavier Van de Woestyne

• vdwxv
• xvw

• Développeur à Dernier Cri ;
• développeur Erlang depuis 2006 ;
• programmation fonctionnelle et systèmes de types ;
• programmation concurrente ;
• after timeout -> finish(phd)
• LilleFP

Roadmap

De plus en plus d'unité de calcul

Oui et une table n'est pas un mobilier...

La programmation concurrente

• Manipulation d'une collection d'entité indépendantes (processus) ;
• ces entités communiquent (idéalement) au moyen d'un bus ;

On admet qu'un programme informatique est une collection de piles sémantiques ordonnancées avant
d'être exécutés dans pile d'exécution ;

• ces piles d'exécutions sont potentiellement des unités de calcul (processeurs/machines).

Derrière tout concept, il existe un formalisme

Le modèle Acteur de Carl Hewitt

• Modèle mathématique proposé au début des années 70 ; (preuves formelles et robotique)
• comme l'objet, il isole le concept par des caractéristiques ;

On considère les acteurs comme les seules fonctions primitives nécéssaires pour la programmation concurrente.
Les acteurs communiquent par envoi/réceptions de messages. En répondant à un message, un acteur peut effectuer un calcul,
instancier d'autres acteurs ou envoyer d'autres messages.
(Il existe une certaine homologie entre les acteurs et les objets qui eux aussi communiquent par envoi/réception de message...)

• Erlang utilise des acteurs (convergence organique) ;
• concept parent d'autres concepts plus modernes (Pi Calcul et le CLoud Computing par exemple).

Un des apports principaux du modèle acteur est que, quand il est implémenté dans un langage,
il fournit une abstraction sur des mécanismes liés à l'exécution simultanée.
Cette abstraction permet généralement de s'affranchir de concepts/outils complexes,
comme par exemple la synchronisation par verrou Et il peut être implémenté à niveau logiciel..

Représentants du genre

• Erlang / Elixir etc.
• Scala (via AKKA)
• Fsharp
• Go
• ... beaucoup d'autres utilisant une bibliothèque dédiée.

La concurrence ... en bref

• Modèle de répartition ;
• implémentable à niveau logiciel ;
• les acteurs sont une manière naïve de représenter un algorithme concurrent ;
• les acteurs permettent d'abstraire certains éléments complexes.

Dans les années 80, chez Ericsson

Bye bye ADA, ils ont besoin d'un langage pour les télé-communications:

• Temps réel ;
• distribué ;
• tolérant aux pannes.

Erlang est développé (avec une toute petite équipe) en extension à la thèse
de Joe Armstrong pour répondre à ces problématiques.

Caractéristiques du langage

• Inspiré syntaxiquement par Prolog ;
• concurrent via des acteurs (envoi/réception de messages) ;
• distribuable très facilement ;
• tolérant aux pannes ;
• fonctionnel, variables immutables, typage dynamique fort, correspondance de motifs ;
• unités de compilation réparties au moyen de module ;
• meta-programmation, flot d'exécution, hot code swapping ;
• très hautes disponibilité (via la distribution et le hot code swapping) ;
• fonctionne sur une VM : implémentation manuelle de processus légers ;
• Glâneur de cellule ;
• Open-source depuis 1998.

Quelques success-stories

• Le chat de Facebook ;
• le commutateur ATM AXD 301 (la classe :v) ;
• de très gros serveur de jeux (Wow, COD) ;
• le protocol Ejabber ;
• CouchBase, Riak, RabbitMQ.

De JAM à BEAM

• JAM : écrit en Prolog (pour diminuer la quantité de lexing);
• BEAM : écrit en C (pour accroître la performance).

C'est en partie à cause (ou grâce) à JAM que la syntaxe de Erlang est ... déroutante.

Constituants majeurs

• Un interpreteur Erlang ;
• un compilateur Erlang ;
• un protocol de communication entre des serveurs génériques ;
• un outil d'analyse statique ;
• une base de données distribuée ;
• une bibliothèque standard assez impressionnante.

OTP comme une collection de foncteurs applicatifs

Comportements et classes statiquement abstraites.

• Une application est vue comme une collection d'outils métiers qui communiquent entre eux ;
• la collection d'outils est régie par un(/des) superviseur(s) ;
• le superviseur principal est encapsulé dans une application ;
• le cycle de vie de l'application est contrôlé de manière distribuable ;
• une application connait ses points d'entrées pour le changement de code à chaud.

OTP est une collection de "design-principles" éprouvée
et hautement réutilisable !

• Let it crash !
• l'arbre de supervision permet d'écrire des applications "tolérantes aux pannes".

Caractéristiques

• Green threads (process) ;
• écrite en C ;
• forte capacité d'interpolation ; (Via Erlport)
• très très performante (GC, bytecode) et distribuable.

VM = byte-code donc potentiellement
plusieurs langages

• Joxa ;
• LFE ;
• Efene ;
• Eml ;
• Elixir ;
• Reia.

Que peut-il apporter ?

• Amélioration de la syntaxe (aurevoir Prolog) et de ses soucis;
• intégration correcte de la méta-programmation (à la Lisp) ;
• tooling ;
• Phoenix framework.

Pourquoi continuer à faire du Erlang

• Eviter le phénomène Scala ;
• comprendre les flots de transformation de programme ;
• enrichir l'éco-système de Elixir en liant des bibliothèques.