Corda: Kotlin

Quand quelqu'un regarde le code Corda , il remarque immédiatement qu'il est écrit en Kotlin - le nouveau langage de programmation de JetBrains, qui peut être compilé pour JVM et Javascript. C'était un choix inhabituel, et dans cet article, je veux partager quelques raisons de cette décision et l'expérience de notre "année avec Kotlin en production".

Pourquoi Kotlin?

Cette solution peut être divisée en deux parties:

1. Quelle plateforme utiliser? JVM, .NET, Node, Python / Ruby, Go, Haskell ou quelque chose de compilé (en code machine)?
2. Quelle langue utiliser si vous choisissez JVM? Java? Sinon, pourquoi? Et sinon, quoi d'autre: Scala, Ceylan, Clojure, Kotlin, Python, Ruby, Javascript ou Haskell (car ils ont tous une implémentation pour JVM).

Les raisons du choix de JVM comme plate-forme sont bien connues dans l'environnement des applications d'entreprise, et il n'y a pas grand intérêt à s'y attarder. Il suffit de dire que si vous avez besoin d'un runtime multiplateforme évolutif, thread-safe avec garbage collection , et avec de nombreuses bibliothèques bien documentées qui résolvent les problèmes métier de base, alors le choix est réduit uniquement à JVM et .NET.

Au début des travaux sur Corda, le projet n'avait pas de nom et il était difficile d'imaginer qu'à l'avenir il deviendrait un produit. En fait, lorsque le projet, qui est devenu Corda, a commencé en décembre 2015 (lors de mon premier jour de travail), il n'était pas prévu de créer un nouveau système comptable distribué pour l'entreprise. Corda a commencé comme un ensemble de prototypes pour explorer de nouvelles idées et exigences qui intéressaient le groupe de travail sur l'architecture du consortium, en particulier celles liées à la visibilité limitée des données et au modèle de données qui fournit l'évolutivité de «l'ensemble UTXO de tableaux de sortie transactionnels» ainsi que la programmabilité des contrats intelligents Ethereum impératifs en général.

En raison du fait qu'il n'était pas clair si ces prototypes se transformeraient en quelque chose, ou serviraient simplement d'information pour d'autres produits sur le marché, nous avons été confrontés à un choix difficile. D'une part, nous voulions explorer rapidement et de manière productive des algorithmes et des structures de données. D'un autre côté, il devrait rester une opportunité potentielle de créer un grand produit d'entreprise et d'embaucher rapidement des personnes pour cela.

Java répondait certainement à ces exigences, mais le manque de fonctionnalités modernes dans le langage réduit considérablement la productivité et, plus implicitement, le moral des développeurs.

Le typage dynamique n'a pas été pris en compte - les avantages de la correction, des outils de développement et des performances fournis par le typage statique sont trop importants pour être négligés.

Les langues fondamentalement différentes des plus populaires n'ont pas non plus été prises en compte, car nous voulions pouvoir engager des experts financiers. Et, bien qu'il soit tout à fait possible de créer une équipe autour d'une langue comme Haskell, trouver une personne avec une expérience bancaire sérieuse et des langues paresseuses (paresseuses) pures (fonctionnelles) vivant au hasard à Londres semblait risqué. De plus, la nature même du produit impliquait que nos "utilisateurs" sont en fait des développeurs de plugins et d'applications qui utilisent la plate-forme, et il est inutile de les obliger à apprendre des paradigmes et des outils complètement nouveaux. Notre choix de langue ne doit pas trop limiter les utilisateurs.

En conséquence, ces exigences nous ont laissé avec Kotlin, Scala et Ceylan. Ces langues sont assez similaires et assez intéressantes. Nous avons choisi Kotlin pour les raisons suivantes:

• Intégration presque transparente avec Java
  
  • En particulier, les programmes Kotlin utilisent une version améliorée (améliorée par le compilateur) des collections JDK standard, ce qui garantit ainsi qu'il n'y a aucun problème d'intégration en raison de l'utilisation d'autres bibliothèques de collections. Nous transmettons et recevons des collections vers et depuis les bibliothèques Java partout, il est donc important que cela ne pose pas de problème.
  • À partir des classes Kotlin, nous obtenons une API Java simple avec les méthodes get / set / is conformément aux types. Aucune annotation spéciale ou autre action n'est requise pour cela. Pour la raison que Corda fournit une API conçue pour une utilisation transparente par les développeurs Java, c'est un grand avantage: à partir du code ordinaire, vous obtenez une API qui ne peut pas être distinguée de l'API Java avec seulement quelques mises en garde (par exemple, l'interception explicite des exceptions vérifiées de Java nécessite une explicite annotation de méthode)
• L'inclusion de petites fonctions comme map / filter / fold / groupBy (au lieu d'espérer que la JVM le fera elle-même) est effectuée par le compilateur. Malheureusement, le compilateur JIT JVM, bien qu'excellent dans l'ensemble, n'élimine pas dans tous les cas la surcharge d'utilisation abondante de fonctions d'ordre supérieur. L'utilisation de Kotlin compense cela, en plus de vous permettre de contrôler l'exécution du programme à partir des fonctions lambda (remarque: par exemple, retour non local ). C'est l'une des fonctionnalités les moins connues, mais en même temps, utiles. Parce que partout où nous écrivons du code dans un style aussi fonctionnel, alors s'il était mal traduit en code machine, nous pourrions nous créer des problèmes de performances.
• En raison du fait que le code sur Kotlin est traduit en un code Java assez similaire, presque tous les outils orientés Java existants fonctionnent immédiatement . Ce n'est pas toujours vrai dans le cas d'autres langues. Par exemple, Quasar a du mal à instrumenter le code Scala car il a besoin d'annotations de méthode, et Scala traduit les lambdas en méthodes qui ne peuvent pas être annotées. Les lambdas Kotlin sont généralement intégrés (voir ci-dessus), ou peuvent être annotés autrement.
• Une excellente documentation et une minuscule bibliothèque standard le rendent très rapide à apprendre. Nous n'avons pas indiqué dans nos offres d'emploi le besoin d'expérience chez Kotlin, et nous avons embauché des personnes à son insu pendant 1 à 3 ans, après quoi un nouveau membre de l'équipe a pu écrire du code idiomatique.
• Sur la base de la sélection des candidats qui nous ont interviewés, IntelliJ est l'IDE le plus populaire (ils avaient un libre choix d'outils). Parmi les langages post-Java, IntelliJ prend le mieux en charge Kotlin.
• J'ai déjà eu une expérience satisfaisante avec lui et, par conséquent, j'étais sûr que ses nouveaux collègues l'apprécieraient également.

Si ce n'était pas pour Kotlin, nous avons probablement choisi Scala: Kotlin s'en inspire largement et les deux sont de bonnes langues.

Notre année avec Kotlin

Comment est-ce - un an pour travailler avec une nouvelle langue dans le contexte d'une application d'entreprise?

La chose la plus importante était, sans aucun doute, d'entendre des collègues qu'ils aiment vraiment travailler avec lui. Le langage de programmation est une affaire personnelle pour tout le monde, et les gens ont généralement une opinion précise à ce sujet. Si vous, en tant que première tâche d'un nouvel emploi, demandez à quelqu'un d'apprendre une nouvelle langue et ne l'avertissez même pas à l'avance, il y a toujours un risque qu'un collègue le déteste et le trouve plutôt ennuyeux plutôt que d'augmenter sa productivité. Mais ce n'est pas le cas.

Voici quelques-uns des problèmes qui surviennent souvent dans un environnement de développement d'entreprise post-Java / C # que nous avons nous-mêmes rencontré:

• Le code est différent selon qui l'a écrit. En général, ce n'est pas un gros problème. Contrairement à Go, qui nécessite un certain style de conception, le code Kotlin de différents auteurs peut être différent. Mais IntelliJ dispose d'un outil de formatage qui fournit un style de base de code unifié. C'est plus limité que pour Java, mais ça suffit. Un problème plus subtil, en particulier avec le code Scala, est l'opposition du style de codage Java-OOP et Haskell-FI. Le code Scala qui utilise des bibliothèques telles que scalaz peut être difficile à lire pour les développeurs qui s'attendent à voir Java amélioré . Dans ce débat, Kotlin est assez fermement du côté de Java amélioré . Et, bien que la programmation fonctionnelle, d'une certaine manière, peut - être sur Kotlin, la communauté (au moins pour l'instant) ne s'est pas divisée en camps. Nous avons eu des cas où le code a été écrit comme s'il s'agissait de Haskell, mais il a été élaboré sur la révision du code.
• Bibliothèques Chez Corda, nous utilisons plus de 50 bibliothèques open source et il n'y a eu aucun problème avec aucune. Nous n'avons jamais écrit de wrappers ou de couches d'adaptateurs. Comme les systèmes de construction dans les projets sur Kotlin, Maven ou Gradle sont généralement utilisés - il n'y a pas de remplacement officiel spécifique à Kotlin pour ces outils (bien que Gradle ait introduit la prise en charge de Kotlin comme nouveau langage de script!).
• DSL et SQL. C # a LINQ, Java a JOOQ et Kotlin a Exposed . C'est l'un des domaines où Kotlin est un peu plus faible que ses concurrents - Exposed est un excellent exemple d'utilisation des capacités de Kotlin pour la construction DSL, mais la bibliothèque elle-même a une API instable et est un projet secondaire. JOOQ, bien sûr, peut être utilisé avec Kotlin et, avec le recul, cela semble être l'option préférée.
• IDE / boîte à outils. Le plugin Kotlin pour IntelliJ est, bien sûr, écrit par JetBrains et, dans l'ensemble, est génial. Cependant, il est moins sophistiqué que le support Java. Les nouvelles fonctionnalités de l'éditeur, telles qu'un indice de paramètre , doivent être portées manuellement sur Kotlin, et le support lui-même, en tant que tel, est généralement en retard sur les plug-ins Java beaucoup plus anciens. Nous avons également remarqué que le plugin IDE notifie assez souvent des erreurs internes, bien que la fréquence des exceptions IDE ait considérablement diminué au cours de l'année (et il semble qu'elles n'affectent rien). L'utilisation d'autres outils ne pose pas non plus de problèmes, car ce qui est écrit pour Java fonctionne généralement hors de la boîte . Une exception est les outils qui fonctionnent avec du code source au lieu du bytecode, et qui, évidemment, ne peuvent pas être réutilisés. Avec tout cela, le compilateur Kotlin et le plugin IDE ne sont pas aussi débogués que dans le cas de Java, même un an après la sortie de 1.0. Très probablement, vous ne rencontrerez jamais d'erreurs internes dans javac , mais, bien que très rarement, nous les voyons toujours dans Kotlin.
• Reconnaissance par les utilisateurs. Les utilisateurs de Corda sont le plus souvent de grandes institutions financières conservatrices. Ces entreprises préfèrent utiliser des langues communes et bien établies. Kotlin, n'étant ni l'un ni l'autre, a clairement causé une certaine surprise au moment où nous avons commencé. "Pourquoi Kotlin?" - C'est une question qui, au cours de l'année écoulée, a pratiquement disparu, car les gens ont regardé de plus près et ont réalisé que ce n'est pas aussi risqué que c'est généralement le cas avec les nouveaux langages de programmation. Nous avons également essayé de faciliter l'adoption en fournissant des exemples de code démontrant que la création d'applications à l'aide de la plate-forme ne nécessite pas de connaissances Kotlin. Les résultats n'ont pas été aussi réussis - de nombreux développeurs travaillant pour la première fois avec Corda commencent toujours par explorer Kotlin. Il n'est pas très clair si cela est le résultat du fait que nous avons fourni des exemples d'utilisation et une documentation insuffisamment orientés Java, ou est-ce juste une bonne excuse pour apprendre un nouvel outil cool. Nous avons également été aidés par l'adoption croissante de Kotlin au sein des principales banques d'investissement. Au cours de la dernière année, plusieurs membres du consortium nous ont dit que leurs équipes de développement interne avaient commencé à examiner sérieusement Kotlin pour leurs propres produits: souvent en raison de la disponibilité d'outils qui convertissent Java en Kotlin, qui fournissent une intégration beaucoup moins pénible dans la base de code existante.
• Support commercial. Le risque d'utiliser des langages peu connus est qu'ils peuvent arrêter de se développer, ou avoir des objectifs qui ne correspondent pas aux besoins formés autour du produit, la communauté des utilisateurs (par exemple, dans le cas des langages de recherche, l'objectif principal des développeurs est de créer des articles scientifiques). La principale raison pour laquelle nous sommes confiants avec Kotlin est que JetBrains est une entreprise stable et rentable qui est sur le marché depuis plus de 15 ans. JetBrains a rapidement commencé à goûter son propre outil en introduisant Kotlin dans le code des principaux produits. Ainsi, le risque de résiliation du soutien est plutôt faible. De plus, JetBrains est déjà une entreprise d'âge moyen, et son marché cible (IDE et outils de développement) a cessé d'être nouveau ou particulièrement à la mode, ce qui réduit le risque d'une éventuelle prise de contrôle de l'entreprise, ce qui peut entraîner des changements stratégiques imprévisibles. Et, malgré l'absence d'un package de support commercial pour Kotlin, dans la pratique, l'équipe résout rapidement les problèmes connus. À l'heure actuelle, JetBrains a l'intention de publier la prochaine mise à jour linguistique après un an depuis la version 1.0. Ce cycle de publication est assez similaire au cycle de développement dans l'environnement d'entreprise.

Conclusions?

On ne le regrette pas: le choix d'une langue jeune au départ de ce projet était, bien que risqué, mais équilibré. Il a fait du bon travail pour nous et nous ne changerions pas notre choix.