BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Utiliser le langage basé sur des acteurs Pony pour la FinTech

Utiliser le langage basé sur des acteurs Pony pour la FinTech

Favoris

Durant sa keynote d'ouverture à la QCon London, Adrian Colyer a mentionné le langage Pony.

Nous sommes familiés avec le fait que les bases de données et les systèmes distribués ont eu beaucoup d'influence l'un sur l'autre dans les 5 dernières années. Maintenant, nous commençons à voir des travaux très intéressants sur les langages de programmation qui entrent dans ce monde. Par exemple Pony, qui vient de l'Imperial College de Londres et est vraiment fascinant.

Nous avons eu la chance d'avoir le designer du langage, Sylvan Clebsch, faire une présentation lors de la track Native Languages. Clebsch a suggéré que Pony est naturellement adapté aux systèmes FinTech puisque "...dans la FinTech, nous n'écrivons pas des logiciels, nous écrivons des processeurs de flux d'évènements dépendants du temps qui sont critiques pour la performance, mais pas vérifiés formellement". Ils sont principalement écrits en Java et C++, mais aussi quelques autres langages comme Scala, C, OCaml, Erlang, R et NumPY.

Pony est un langage natif basé sur le modèle des acteurs avec la sécurité basée sur des capabilities, compilé par LLVM. Le modèle des acteurs est probablement le plus connu à travers Erlang, et plus récemment Akka. Il trouve son origine dans les travaux de Carl Hewitt et d'autres, avec un papier en 1973. Un acteur combine la gestion d'état et des méthodes asynchrones. En plus des champs, un acteur a une file de messages et sa propre heap. Dans Pony, affirme Clebsch, les heaps des acteurs sont garbage collectées indépendamment, et à la différence d'Erlang ou Akka, les acteurs eux-mêmes sont également soumis à garbage collection. Vous ne devez donc pas utiliser un message spécial pour les tuer ; il n'y a en essence pas de gestion manuelle de la mémoire.

Les acteurs collectent leur propre heap indépendamment des autre acteurs en utilisant un algorithme mark-and-don’t-sweep. Cela signifie que Pony est O(n) sur le graphe atteignable ; la mémoire non atteignable n'a pas d'impact. Le GC n'a pas de safepoint, pas de barrière en lecture ou écriture, pas de marquage de card table et pas de compaction. Il n'y a pas besoin de corriger les pointeurs puisqu'il n'y a pas de compaction.

Cela signifie qu'une passe à travers un acteur pour collecter sa heap locale consiste à parcourir le graphe atteignable. Il n'y a pas d'autre action d'aucune sorte. Cela signifie aussi que la quantité de perturbation quand un acteur GC sa heap est faible. Non seulement ça, mais il le fait avant de gérer un behaviour.

Les acteurs n'ont pas d'opérations bloquantes. Ils sont peu coûteux, avec un overhead d'environ 240 bytes comparé à un objet, ou 156 bytes sur une architecture 32 bits comme ARM. Ils n'ont aussi aucun coût pour le CPU quand ils n'exécutent pas de code. Comme Clebsch le dit, "Si un acteur n'a pas de travail à effectuer, il n'est même pas dans une queue. Le runtime ne le connait pas, à moins qu'il n'ait du travail à effectuer".

Les acteurs se transfèrent des messages en utilisant des files de messages intrusives, puisque les messages n'ont pas besoin d'être dans plus d'une file. De façon plus controversée, les files ne sont pas limitées en taille puisque "si la file était limitée, alors quand elle est pleine vous devez soit bloquer soit échouer". Bloquer peut introduire des deadlocks, alors qu'échouer nécessiterait une gestion d'erreur spécifique à l'application chaque fois qu'un message est envoyé. Les files limitées sont utilisées pour éviter le problème de la back pressure selon Clebsch, alors que les files non limitées déplacent le problème de la back pressure, ne l'empirant pas. Actuellement, Pony ne propose aucun mécanisme de back pressure généralisé.

Ce n'est pas la fin du monde : il est plutôt simple d'écrire une back pressure spécifique au domaine, comme la back pressure dans le TCPListener, qui arrête d'accepter de nouvelles connexions quand elles atteignent un certain nombre. Dans les mois qui viennent, la back pressure généralisée va être intégrée dans le runtime. Ce qu'elle fait est de déprioriser les acteurs qui envoient des messages aux files trop chargées.

Fondamentalement, le modèle acteur sert à exprimer la concurrence, et gérer des problèmes complexes de concurrence est le domaine pour lequel Pony a été conçu. La clé de ce design est le système de types qui est sans data-race, concurrency aware et prouvé correct. Selon Clebsch, il n'y a pas d'autre langage avec un type système autorisant la mutabilité et sans data race, bien que Rust atteigne le même objectif avec une combinaison de propriétés du système de types et de comptage de références.

Pony n'a pas de null. Le système de types est construit sur des types de données algébriques, et peut en ce sens être considéré comme un langage fonctionnel. L'exemple suivant, provenant des slides, montre comment créer un ordre sur un système de gestion d'ordres très basique.

Le ReadSeq[OrderObserver] iso nous amène vers l'un des concepts les plus importants du système de types. Iso (Isolated) est une reference capability qui offre une garantie qui est basée sur des deny properties. Ce sont ces reference capabilities (rcaps) qui rendent le système de type sans data race.

Clebsch affirme : "Ce n'est pas ce que vous avez le droit de faire, c'est ce que leur existence prouve qu'il ne peut pas exister autre part dans le système de types". Isolated indique qu'il interdit à la fois les alias locaux et globaux qui pourraient lire ou écrire dans l'objet. C'est une garantie d'interdiction incroyablement puissante. Elle signifie que ce qu'au maximum quelqu'un d'autre peut connaître à propos de cette référence est son adresse. Ils ne peuvent pas lire ou écrire ses champs. Il est donc sûr de l'envoyer à un autre acteur, alors qu'il reste mutable sans locks d'aucune sorte".

Rcaps sont des annotations de types qui indiquent un niveau d'isolation ou d'immutabilité : x: Foo iso // Un Foo isolé x: Foo val // Un Foo globalement immutable x: Foo ref // Un Foo mutable x: Foo box // Un Foo localement immutable (comme const en C++)
x: Foo tag // Un Foo opaque

Il est important de noter que cette garantie d'absence de data race est gérée par le compilateur durant la vérification des types, ce qui signifie qu'il y a une croissance non linéaire dans le travail que doit effectuer le compilateur avec l'augmentation de la taille de la base de code. Colyer fournit un résumé fantastique (en anglais) du papier qui décrit cela avec plus de détails sur son blog Morning Paper.

Rcaps autorise les objets isolated (iso), immutable (val) et opaque (tag) à être passés par référence entre acteurs. Il faut donc un moyen d'empêcher la collecte prémature des objets dans les messages (où il est possible qu'aucun acteur n'ait de référence) ou qui sont atteignables par d'autres acteurs. Pony utilise pour cela un protocole de messages décrit dans un papier qui a aussi été traité par Colyer. Cette approche est analogue à un algorithme de consensus, et Colyer fait des parallèles avec l'algorithme de snapshot distribué de Chandy-Lamport.

Le papier Pony, "Ownership and Reference Counting Based Garbage Collection in the Actor World" – Clebsch et al. 2015, affirme :

Quand un acteur envoie, reçoit ou supprime une référence à un objet qu'il ne possède pas, il envoie un message spécifique du protocole au propriétaire. Ces messages font modifier un compteur de référence local par le propriétaire de l'objet.

Pony est encore dans son jeune âge et quelques éléments significatifs tels que la réflexion et le chargement à chaud de code sont des problèmes non triviaux et non encore résolus. Bien qu'une étude récente suggère que la plupart des utilisateurs sont encore en train de jeter un oeil sur le langage, certains sont plus avancés. Par exemple, Sendence, une société de New York, a un produit pour la FinTech qu'ils prévoient de passer en production bientôt.

Pony est un langage open source et les contributions sont les bienvenues. Il y a aussi une Sandbox pour le tester.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT