RubyRussia 2019. Nikita Shilnikov sur les effets algébriques

Il reste très peu de temps avant la conférence RubyRussia. Ceux qui n'ont pas réussi à obtenir leur billet ont encore la possibilité de récupérer l'un des derniers sur le site . Nikita Shilnikov lors de la conférence parlera des effets algébriques, mais pour l'instant vous pouvez lire l'interview sur le sujet du rapport.



Dites-moi ce que vous faites et comment est-ce lié à Ruby?

Je travaille pour deux entreprises dont les projets sont écrits en Ruby. Dans l'un, nous faisons de la facturation, nous pouvons dire qu'il s'agit d'une telle semi-entreprise, et dans un autre, nous créons un service SaaS. Il se trouve que je fais beaucoup d'open source. Il y a quatre ans, je me suis intéressé à un projet, y ai trouvé des failles de fonctionnalité, j'ai décidé de le réparer, et ainsi de suite. Maintenant, je suis le développeur principal de deux organisations et de la communauté. Tout peut être vu sur mon github . Une partie du travail porte sur les bases de données rom-rb , et l'autre dry-rb est un ensemble de bibliothèques pour différentes occasions.

Votre rapport sur les effets algébriques, dites-moi quels avantages ils offrent aux développeurs.

Ici, vous avez besoin d'une petite interview. L'écosystème dry-rb s'inspire de la programmation fonctionnelle. Mais lors de son développement, quelque chose a hanté. Par exemple, vous développez un service SaaS et il y a une tâche simple d'isoler les données. Tout semble clair, il existe une sorte de service, les entreprises y sont enregistrées et elles ne devraient pas avoir accès aux données des autres. Vous pouvez résoudre de nombreuses façons. Mais d'un point de vue purement fonctionnel, je n'ai pas pu trouver de réponse à la façon de procéder, à l'exception du transfert explicite des arguments dans tout le code. Il a proposé sa solution «non fonctionnelle» et a vécu avec lui.

Fin 2018, des hameçons sont apparus dans React. Quand j'ai vu leur API pour la première fois, j'ai pensé qu'il était impossible de faire de telles choses si simplement. J'ai une bonne idée du fonctionnement de JavaScript et j'ai décidé que tout n'est évidemment pas propre ici, que des variables globales sont utilisées ou autre chose. Dans mon idée du fonctionnement du programme, c'était soit impossible, soit une sorte de hack sale a été utilisé. J'ai décidé d'étudier la question.

Il s'est avéré que je n'étais pas la seule personne intéressée par ce sujet. J'ai trouvé des informations selon lesquelles il existe un tel moyen de formalisation, c'est-à-dire l'écriture de programmes qui semblent utiliser des variables globales ou un état général. Cependant, ils seront toujours propres. Le problème était pertinent et j'ai commencé à creuser plus profondément. En conséquence, les effets très algébriques sont devenus la réponse. J'ai écrit un petit prototype en Ruby et, à ma grande surprise, cela a fonctionné. Mis en œuvre en production, lancé et conduit pendant plusieurs mois, puis a pris une décision pour tout le monde.

Vous m'avez intrigué directement avec les crochets React. Je pensais qu'il y avait quelque chose de très simple comme la pile d'appels, la fermeture, la portée actuelle.

Ça l'est vraiment. Le problème est que vous avez une sorte d'article qui décrit la sémantique et comment, d'un point de vue scientifique, cela devrait fonctionner. Si vous suivez les spécifications, il semble que vous puissiez créer une bibliothèque. Dans le cas de React, il s'agit également d'une bibliothèque ou, disons, d'un framework qui fournit une sorte d'API. Si vous l'utilisez correctement, alors tout fonctionne bien. Mais si vous allez à gauche ou à droite, cela peut mal finir. Dans React, ils ont simplement interdit l'utilisation d'hameçons dans certaines conditions. Ils devaient le faire. C'est une des limitations.

Est-ce en quelque sorte lié à la preuve mathématique de l'exactitude du code?

Pas vraiment. Il ne s'agit pas de la nécessité de prouver quelque chose, la question va plutôt dans le sens de la vérification du programme. Les effets algébriques ne sont qu'une description de la sémantique. Rien n'y est prouvé, mais il montre comment cela devrait fonctionner. Si cette bibliothèque, qui implémente des effets algébriques, ne contient pas d'erreurs en soi, alors en décrivant la sémantique, vous garantissez que votre code fonctionnera comme prévu.

Que pensez-vous des types et des langages de programmation typés statiquement?

Très positif. Par exemple, nous avons un backend sur Ruby et un frontal sur une chose telle que ReasonML. C'est OCaml, mais avec une syntaxe différente. Toutes choses égales par ailleurs, je fais un choix dans le sens de ce type de système. C'est assez simple et il existe un certain nombre de langues dans lesquelles une implémentation similaire ou similaire. Plus il y a de types, mieux c'est. Cependant, j'écris un backend en Ruby et tout va bien pour moi. Je suis le développeur des outils avec lesquels je travaille et ils ont toujours été de type: dry-types , dry-struct , dry-schema , dry-validation , dry-monads . Il s'agit de décrire les types qui proviennent de la base de données, de l'utilisateur, de systèmes externes. Vous savez donc toujours quel code Ruby vous convient. Même s'il n'est pas tapé par lui-même, vous pouvez être sûr du type de variable avec laquelle vous travaillez.

Il y a des rumeurs selon lesquelles il y aura des types dans Ruby 3. Qu'en dites-vous?

J'ai de l'expérience avec Python. Quand les types ont été amenés là-bas, le tuling n'était pas très développé et je n'ai pas été impressionné. Maintenant, la situation est meilleure là-bas. Vous pouvez y aller et tout décrire avec des types et appliquer une sorte de réglage, qui vérifiera que votre programme est correct. Il s'agit d'une sorte de remplacement du compilateur, de ce que fait actuellement le sorbet. Cela a pris plusieurs années pour Python. J'accueille toujours favorablement le mouvement vers les types, mais je ne me fais aucune illusion.

Vous recherchez une nouvelle syntaxe que vous prévoyez d'implémenter en termes de code Ruby?

Surtout pas joué, est entré dans le chat, a regardé. Mais je n'ai aucune opinion sur la façon dont cela vaut la peine d'être mis en œuvre. La syntaxe peut être améliorée, les changements de langue, etc. Maintenant, ils ont créé la syntaxe compatible Ruby habituelle. Je ne pense pas que la syntaxe soit une pierre d'achoppement ici, une pierre d'achoppement est le réglage et, comme je l'ai dit, c'est un très long chemin.

Qu'aimeriez-vous voir d'autre dans Ruby, comment voyez-vous son développement?

Je serais intéressé par le multitâche coopératif. Nous avons déjà un multitâche coopératif sous forme de fibre. Nous n'avons toujours pas la possibilité de les exécuter sur plusieurs threads. Il existe des options sur la façon dont cela sera fait et il n'est pas clair sous quelle forme. Étant donné que Ruby, l'implémentation C a un héritage assez solide, Matz ne veut pas rompre la compatibilité descendante. Je suis enclin à une combinaison de fibres et de plusieurs fils fonctionnant simultanément. Peut-être que quelque chose comme Guild fonctionnera.

Cette année, Yukihiro Matsumoto, l'auteur de Ruby, vient à la conférence. Que seriez-vous intéressé à discuter avec lui autour d'une tasse de café ou d'un verre de saké à l'afterparty?

La meilleure chose que nous puissions faire en communiquant avec les auteurs de langues ou même de bibliothèques est de leur montrer comment nous utilisons ce produit dans la vie réelle. De plus, même si les auteurs ne s'y attendaient pas. Cela donnera à l'auteur la possibilité de prendre en compte cette expérience et de l'appliquer dans le développement ultérieur. Je voudrais montrer toute l'histoire avec des effets algébriques. Je dirais - regardez, que peut-on faire dans le langage miracle que vous avez créé. Et peut-être qu'après cela, il trouvera quelque chose d'autre pour nous.

Rendez-vous à RubyRussia!

Rappelons que la conférence a déjà lieu ce samedi, les inscriptions sont toujours ouvertes.

Il y aura non seulement des rapports, mais aussi des stands des meilleures entreprises:

Organisateur - Evrone
Associé commandité - Toptal
Partenaire Gold - Gett
Partenaires Silver - Valarm , JetBrains , Bookmate et Cashwagon
Partenaire Bronze - InSales