Sur les traces du mouvement russe Scala. 3e partie

Ceci est la dernière partie de l'enquête sur le mouvement Scala en Russie. Dans la première partie, j'ai appris de Roman Grebennikov sur le beau monde de Voronej, C ++ et Erlang, et de Roman Timushev sur le premier Akka et la naissance des réunions de Moscou. Dans la deuxième partie, j'ai parlé avec Alexander Podkhaluzin et Mikhail Mutsyanko : apprendre à connaître Scala, 2007, Scala Days, Scala Native, déménager à Kotlin, Scala est bon pour les banques, les premiers événements à Saint-Pétersbourg, Eclipse, Jason Zaugg, IDE et Scala Plugin.



Lors de la préparation de la deuxième partie, Vladimir Uspensky ( vuspenskiy ) m'a dirigé vers Alexander Podkhalyuzin , avec qui nous avons enregistré une énorme interview. Le lendemain, j'ai reçu un message de Vladimir, mais maintenant avec son histoire personnelle: Qiwi, Scala à Tinkoff, premières réunions, liens vers d'anciens blogs (merci spécial pour cela), et fonctionnalisme de 2008 de Rúnar, qui s'exécute à Java, - c'est encore du sang des yeux, du moins inhabituel. En outre - les histoires de Roman Elizarov , Alexei Fomkin et Nikolai Tatarinov . Caractéristiques de l'embauche de développeurs Scala, cours sur Coursera, «code parfait», compilation «démoniaque», conception en Kotlin, 10 000 lignes de code, services bancaires par Internet Tinkoff, encore une fois Tinkoff, Play Framework, est décédé Flash, réunions «Sunrise» et Saint-Pétersbourg - à propos de tout cela dans la dernière partie de la trilogie sous la coupe.

Vladimir Uspensky: Coursera, Tinkoff et fonctions d'embauche pour Scala

Vladimir : A cette époque, je travaillais chez Qiwi et refactorisais beaucoup de code Java, mais j'ai quand même eu beaucoup d'eau et un passe-partout. J'étais tourmenté, mais d'une manière ou d'une autre je me suis humilié.

Après un certain temps, je suis allé sur les blogs d' Alexander Temerev et Vlad Patryshev . Vlad était à l'avant-garde dans la mise en œuvre de Java, si je comprends bien. J'ai lu sur Scala avec eux, j'ai commencé à remarquer des mentions de constructions qui m'étonnaient alors, comme des options en Java . J'ai même lancé cette option quelque part en production. Il y avait plus de gestion des erreurs paresseuses exotiques en Java et le parallélisme Java d'ordre supérieur par Rúnar Bjarnason . Tout cela a terriblement fait exploser le cerveau et se demandait comment appliquer tout cela.

Quand j'ai étudié des exemples spécifiques, par exemple, de Daniel Spiewak : Scala for Java Refugees , c'est exactement ce qui me manquait. Toute l'eau et les incohérences étranges comme `_` vs `*` vs `?` Du code Java ont `_` vs `*` vs `?` , et l'essence demeure.

C'était Scala 2.7 et, pour le dire avec légèreté, ce n'était pas stable. De nombreux projets l'ont essayé pour des tests unitaires ou des classes de cas. Pour ajouter Scala à un projet Java, vous avez dû configurer la compilation conjointe dans Maven . Mais j'ai décidé d'essayer d'ajouter un support à un projet non critique à Qiwi. Tout a fonctionné - j'étais très heureux, mais c'est là que ça s'est terminé.

Travail chez Tinkoff et Scala Implementation

Soudain, j'ai été invité à Tinkoff pour diriger le développement d'une nouvelle banque Internet, qui a été entièrement développée au sein de l'entreprise. Au début, j'ai compris les tâches en cours, mais quand je suis arrivé au backend, j'ai réalisé qu'il était temps d'implémenter Scala.

Je viens de sortir Scala 2.9 avec une syntaxe moderne à l'époque. Les collections parallèles à la mode étaient parfaitement adaptées pour exécuter quelque chose rapidement en parallèle, si les détails ne sont pas importants. Et le créateur de Groovy James Strachan a publié : "Je peux honnêtement dire que si quelqu'un m'avait montré le livre Programming Scala de Martin Odersky, Lex Spoon & Bill Venners en 2003, je n'aurais probablement jamais créé Groovy."

Un autre facteur dans le choix de Scala est que toutes les personnes qui ont ensuite travaillé sur les outils, le langage, les bibliothèques ou ont écrit sur Scala étaient super intelligentes et énergiques. Par conséquent, il était certain que c'était le bon choix pour l'avenir.

Tout en travaillant à la banque, j'ai commencé à assister à des conférences à l'étranger. Les premiers Scala Days en 2012, le flat geek geek à Oslo. A cette époque, j'ai rencontré Zhenya Burmako . Maintenant, nous nous promenons parfois le long de l'océan déjà ici en Californie.

Embauche de développeurs Scala

A progressivement écrit une banque en ligne. En 2012, il est devenu le meilleur de Russie selon Global Finance . Pour moi, c'est une confirmation de la déclaration «Faites-le normalement, ce sera normal», et pas quelque chose d'extraordinaire.

Oleg Tinkov a fait la promotion du sujet de la banque, ce qui était drôle. Cela nous a peut-être aidé à embaucher de bons développeurs - des gens faisaient partie de l'équipe, mais je voulais m'étendre. Tout d'abord, nous avons écrit dans la vacance "Java-programmer, Scala - plus." Mais mentionner Java dans les emplois pour les développeurs Scala coupe les gens qui ne veulent rien avoir à faire avec Java. Par conséquent, nous avons changé le poste vacant en Scala Senior Developer. Cela m'a permis d'embaucher un couple de gars avec qui j'aimerais beaucoup travailler un jour.

Groupe Facebook

Je voulais comprendre qui, en général, en Russie et à Moscou, était également intéressé de manière indépendante par Scala, et quel genre de pensées la communauté avait. Il n'y a eu ni réunions ni discussions, et l'idée était de rassembler tout le monde. Il a fait un groupe sur Facebook , dans lequel nous avons planifié les premières rencontres. Qu'est-ce qu'une réunion sans groupe au Meetup ? Je suis allé créer, mais le groupe existe déjà - Roman Timushev a créé. Nous avons décidé d'unir nos forces et avons ajouté Misha Aksarin .



La première réunion a été réunie sous prétexte d'un cours Scala sur la programmation réactive sur Coursera . Beaucoup ont regardé, mais une vingtaine de personnes sont venues: elles se sont rencontrées, ont dit qui elles faisaient et étaient intéressées, ont discuté des exercices du cours et ont convenu de se rencontrer à nouveau.

Alors ça a commencé.

Roman Elizarov: 10 000 lignes sur Scala, perfectionnisme et compilation impitoyable

Roman Elizarov ( elizarov ) - chef du groupe JetBrains, a participé aux travaux sur les coroutines, les bibliothèques de Kotlin.

Note de l'auteur . Avant d'enregistrer l'interview, je pensais que ce serait un désastre si je ne les prenais qu'à des personnes impliquées dans Scala. «Adoration» continue ou, pire, «erreur du survivant». Par conséquent, j'ai décidé d'ajouter définitivement une mouche dans la pommade.

C'est plus difficile - les personnes ayant une expérience réelle qui, pour une raison quelconque, ne sont pas entrées dans la langue sont un ordre de grandeur plus petit que les ennemis sans expérience de Scala. Mais ensuite je me suis souvenu du poste de Roman Elizarov ( elizarov ) - le chef du groupe JetBrains - dans lequel il a griffonné sur la Scala entre les caisses, ce qui a provoqué de multiples burnouts, dont le mien. Malgré le négatif, il est peu probable que Roman ait écrit un article sur certaines rumeurs sur la langue. Il doit y avoir une raison, une sorte d'expérience négative d'utilisation - cela s'est avéré ainsi. Ci-dessous l'interview avec lui est juste à ce sujet, et quelques discussions sur la conception et la connexion de coroutine avec Scala CPS Plugin.

Cas en 2010

Roman Elizarov : Vers l'an 2000, j'ai programmé toutes sortes d'enterpases en Java. Par conséquent, j'ai suivi les langages JVM, y compris Scala. Il semble que la première fois que j'ai lu sur la langue autour de 2005-2006.

Lorsque vous lisez de manière abstraite, la syntaxe est plutôt cool. Je me souviens avoir lu la description, joué et j'ai vraiment tout aimé. Beaucoup de choses en Java qui sont détaillées et difficiles à travailler sont faciles à faire dans Scala. Tout cela m'intéressait déjà alors, non pas du point de vue de FP, mais du point de vue pragmatique - au moment où nous écrivons le code. Mais, comme la base de code Java est déjà volumineuse, un tas de classes actuelles, il n'a pas été possible de l'utiliser dans la pratique jusqu'à ce que l'histoire se produise en 2010.

En 2010, nos partenaires des États-Unis, de l'entreprise, s'ennuyaient. Ils voulaient de la nouveauté, et ils ont écrit un nouveau sous-système entièrement sur Scala. Il avait une sorte d'interface Web, il faisait quelque chose de simple. Dans le même temps, ce n'est pas le Play Framework - juste un service Web reçu des demandes des utilisateurs, appelé l'API Java. Un site Web normal pour effectuer une sorte de fonctions interactives internes. Les partenaires entaillent, cela a fonctionné avec succès, tout va bien.

À cette époque, nous étions leurs sous-traitants. Les développeurs du sous-système ont suffisamment joué et ont décidé de faire autre chose. Nos clients viennent nous voir et disent: «Les gars, prenez cette chose pour du support? Elle utilise quand même votre API. " Génial, le voici - une vraie façon d'essayer avec Scala. Donc, personne ne nous permettrait de programmer à Scala, car tout est difficile, mais comme il y a déjà un projet, c'est la raison. Il s'agit en fait de la première expérience de production avec Scala.

La première impression de Scala est la compacité du code par rapport à Java . Scala vous permet d'écrire des choses complexes de manière compacte. Le sous-système a pris environ 10 000 lignes de code, mais en Java, il en faudrait deux fois plus à cause des classes. La syntaxe, tous les objets internes pour le transfert de données, même l'adaptation complète de l'API Java sont tous compacts.

Première et dernière 10 000 lignes sur Scala

Lorsque les développeurs sont partis, ils ont laissé le code non assemblé - dans le sens où il ne s'agissait que de code . Nous avons essayé de le prendre en charge, mais il y a eu un problème de compilation.

Compiler le code Scala est une quête. Le code se compile uniquement avec une version spécifique de Scala Compiler - précise à la version ponctuelle, à la version du correctif. Une version plus grande ou plus petite n'est plus compilée .

Cela a décidé pour moi en 2010 du sort de Scala en entreprise, où il y a des millions de lignes de code. C'est effrayant d'imaginer comment vivre si vous changez la version mineure du compilateur et que vous n'y allez pas.

"Vous ne vous souvenez pas exactement pourquoi?"

Roman Elizarov : pourquoi il s'effondrait, je ne me souviens pas, bien sûr. Quelque chose changeait constamment de version en version. Peut-être que nous étions au mauvais moment?

Mais j'ai continué à surveiller le développement de Scala, malgré le fait que ce n'est que dans l'entreprise que nous ne l'avons pas mis en œuvre. En conséquence, la fonctionnalité a été transférée vers d'autres applications Java. À ce Scala dans cette société a cessé d'exister.

Ces 10 000 lignes étaient les premières et les seules. Le code a fonctionné pendant longtemps dans la production, mais il a ensuite été analysé par d'autres services et éliminé.

Spécifiquement pour mon activité professionnelle, cette expérience a laissé une marque indélébile, dans le sens où, néanmoins, la compatibilité de tout cela est nécessaire. Maintenant je fais du Kotlin. Il n'est pas surprenant que nous passions simplement un temps irréaliste et des forces supplémentaires pour assurer la compatibilité de tout et de tout. Parfois, un temps fou ne va pas dans la fonctionnalité, mais simplement pour que tout soit compatible. En particulier, mon expérience passée affecte cela.

Rappelez-vous toujours Python. Concernant la compatibilité, nous avons deux bugs: Scala et Python. En matière de compatibilité, personne ne veut répéter la transition de 2 à 3 Python, et personne ne veut être comme Scala.

"Code parfait"

- Souvent, vous voulez refaire quelque chose pour que tout soit «chocolat»?

Roman Elizarov : Je suis engagé dans le design et je veux constamment tout refaire . Je n'aime jamais ce que j'ai fait. Pendant que je prépare quelque chose pour la sortie, je trouve quelques choses que je veux changer. Dès que j'ai dévoilé quelque chose, j'y vois déjà des défauts: il n'est pas encore terminé, ici nous devons le réécrire à partir de zéro. Mais c'est la route vers nulle part. Il n'y a que deux approches: soit j'améliorerai le code indéfiniment et n'atteindrai jamais la version, soit je lancerai la version et elle deviendra Legacy. Vous ne pouvez pas publier le code parfait .

Ensuite, je passe la moitié du temps à améliorer le produit et la seconde à la compatibilité avec ce que j'ai déjà sorti. L'expérience aide à «poser des pailles» à l'avance. Je vois que je vais devoir le refaire bientôt, et passer beaucoup de temps au moment de la sortie sur filet de sécurité en prévision de futurs changements. Bien sûr, faire quelque chose à partir de zéro et ne pas se soucier de la compatibilité est beaucoup plus facile. Mais le compromis est que vous le faites parfaitement ou qu'ils utilisent votre produit. L'un exclut l'autre.

Le design chez Kotlin

Roman Elizarov : J'ai constamment suivi Scala, parce que lorsque nous concevons quelque chose en Kotlin, nous étudions ce que les autres langues ont, y compris Scala. Il y a environ deux ans, nous avons conçu des coroutines Kotlin. La principale «inspiration» est, bien sûr, C #. Tout a commencé avec lui et de là est déjà né c'est tout. Ensuite, nous avons commencé à étudier Go.

Lorsque la conception a commencé à s'écarter de C # et que des «continuations» sont apparues, puis des «continuations délimitées», nous avons recommencé à étudier d'autres langages. Chez Google, je tombe sur Scala - il s'avère qu'il y avait déjà des « suites délimitées ».

- Parlez-vous du plugin de compilation?

Roman Elizarov : Oui. En même temps, le design était incroyablement similaire à celui qui est maintenant à Kotlin. Il y a bien sûr une différence syntaxique: dans Kotlin, nous écrivons le modificateur de suspension au début, et dans Scala vous avez écrit l'annotation csp sur la valeur de retour. Mais quelle est la différence où mettre le modificateur: dans le type de valeurs de retour ou au début?

La conception de Scala était très similaire à celle de Kotlin. Je me suis intéressé - comment se fait-il, vu un design aussi cool, pourquoi ça n'a pas volé? Pourquoi personne n’écrit comme ça dans la Scala moderne? Ils m'ont montré comment ils écrivent dans le Play Framework - il n'y a pas de plugin là-bas.

Tout le monde écrit des futures, et nous avons eu une excellente idée de nous débarrasser des futures, car cette conception est plus pratique. Et c'est ce qui s'est passé à Kotlin: les futurs ne sont pas nécessaires, il y a des coroutines. A Scala, ils ont abandonné les "suites" et n'ont pas volé. Pourquoi?

L'insensé et l'impitoyable de la compilation

Dans le processus de recherche, j'ai trouvé l' annonce la plus originale. Cette année-là, des «suites délimitées» sont apparues à Scala. A Scala, tout a été fait comme à Kotlin.

L'annonce en ce sens est indicative. Il a dit: "Nous avons fait" des suites délimitées ", regardez, nous pouvons écrire les mêmes trucs sympas qu'en Lisp." Par exemple, nous avons pris un exemple sur Lisp des travaux des années 80-90, et l'avons réécrit sur Scala: les listes sont ancrées, ici «shift / reset». En Lisp et dans des langages similaires, il existe une construction pour les continuations délimitées , qui est désignée comme «shift / reset». Le nom explose le cerveau - personne ne sait ce qu'est le changement / réinitialisation. Ni celui qui a étudié Lisp, ni celui qui ne l'a jamais rencontré.

La principale chose dans cette annonce est des commentaires comme celui-ci: «Cela n'a pratiquement aucun sens. Je viens de passer du temps sur Wikipédia ainsi que quelques autres endroits pour essayer de comprendre cela. De mon point de vue, ce sont des façons compliquées d'ajouter des chiffres et je n'ai aucune idée de ce qui est gagné ou accompli. " Ils expliquent l'essence du poste.

Par conséquent, une telle annonce d'une caractéristique importante est absolument inutile. S'il est lu par une personne qui écrit du code pour l'application, il ne recevra pas de réponse à la question: «Pourquoi en ai-je besoin? Quel problème cela résoudra-t-il? »L'auteur n'a pas soulevé une telle question. Par conséquent, la fonctionnalité n'a pas volé - non pas parce qu'elle était mauvaise, mais parce qu'il n'y avait aucune tâche à piloter .

"A-t-elle été mal appliquée?"

Roman Elizarov : Oui, ils se sont trompés. C'était comme si cela avait été annoncé, mais ils n'ont pas expliqué pourquoi cela était nécessaire et quels problèmes cela pouvait résoudre. Mais la question n'est pas la «justesse» ou la beauté. Soit dit en passant, chez Kotlin, nous ne savons pas non plus comment écrire de beaux articles de blog, mais écrire un bon article ne suffit pas pour écrire une belle annonce. La présentation correcte n'est pas tant une explication du pourquoi, mais aussi une explication du point de vue de l'API .

J'ai lu le code, et là, les méthodes shift / reset sont utilisées. Pourquoi l'appelait-on shift / reset dans les années 70? J'ai essayé de trouver l'auteur du nom du passé, mais je n'ai pas réussi. Juste quelqu'un a trouvé ce nom. Pour un programmeur moderne, ces mots ne disent rien du tout. Ils ne veulent rien dire.

Je traite tellement les coroutines qu'il semble que je devrais tout savoir à leur sujet, car j'ai lu un tas d'articles scientifiques. Mais quand je vois un code qui utilise «shift / reset», je m'efforce à chaque fois de comprendre ce qui s'y passe et pourquoi il est nécessaire. Cela ressemble à une sorte de magie noire, sans signification.

Alexey Fomkin: le défunt Flash, Voskhod et les premières rencontres à Moscou

Alexey Fomkin ( yelbota ) - programmeur, conférencier, podcast, contributeur Open Source, passionné de Scala.

Note de l'auteur . Après s'être retiré des affaires de Timushev et Uspensky , tout le mouvement à Moscou reposait sur Alexey Fomkin . En outre, il a lancé le podcast Scalalaz et a regardé d'autres podcasts: DevZen , Debriefing , Remote Talk . Le sauter dans cette série d'articles serait une grosse erreur.

De votre entreprise à un développeur Scala

Alexey Fomkin : Je serai probablement très ennuyé - il n'y avait rien d'intéressant. J'ai mon histoire personnelle. C'est intéressant pour moi, mais pour les lecteurs, cela peut être ennuyeux.

En fait, j'étais impliqué dans Action-Script, et plus tard, j'avais ma propre petite entreprise. Lorsque l'entreprise a fermé, je me suis retrouvé sans tout, car Flash était mort à ce moment-là. En conséquence, il n'y avait rien d'autre dans mon curriculum vitae. Je cherchais du travail, j'étais déprimé émotionnellement parce que j'avais tout perdu.

Je ne me voyais pas comme un directeur technique, pas même comme un chef d'équipe. Après un échec avec son entreprise, il n'y avait qu'une ambition pour un programmeur ordinaire. J'ai essayé d'obtenir un développeur JS dans Yandex. Mais ils m'ont refusé parce que je ne le connais pas bien - ce qui était vrai, bien sûr.

Puis j'ai pensé à Scala. Je l'ai essayé plusieurs fois, à partir de 2010 - j'aime la langue. J'ai essayé parce que dans le bureau où je travaillais en 2010, il y avait Oaml. Je voulais, comme OCaml, juste avoir une JVM - j'ai bien aimé. A côté, j'ai écrit plusieurs projets sur Scala, et en 2014 j'ai commencé à postuler dans mon entreprise.

Il y avait une idée pour évoluer vers Scala: il y a beaucoup d'offres, beaucoup de projets, et les développeurs sont en nombre insuffisant. Puis je me suis tendu et en quelques mois, j'ai remonté et mis à jour toutes mes connaissances. J'ai eu de la chance - j'ai eu un directeur technique et j'ai tapé l'équipe Scala.

Voskhod, chat Skype et organisation des premières rencontres

En même temps, je pensais que nous devrions essayer de remuer certaines choses, jusqu'à ce que le sujet ne soit pas très développé en Russie. Il a parlé avec Uspensky , Timushev et Askarin . Il s'est avéré que Askarin a été laissé seul - Uspensky était «sur les valises». J'ai parlé de faire Meetup ou non. "Oui, nous le sommes." Et ce fut le dernier mitap organisé par l'ancienne équipe. C'était dans une institution d'État, l'Institut de recherche «Voskhod». J'y suis allé, j'ai parlé de Scala JS ou quelque chose, puis ce sujet s'est complètement éteint. Comme tout est si mauvais et qu'il n'y a pas d'activité, j'ai décidé de tout organiser moi-même - j'ai commencé à devenir actif dans un chat Skype, dans lequel les Rocheuses traînaient.

- Combien de personnes y avait-il?

Alexey Fomkin : Je ne me souviens pas - il n'y en a pas beaucoup dans le chat moderne. L'épine dorsale principale est de 10 à 50 personnes qui parlent constamment. Le reste vient, va, pose des questions - comme maintenant.

C'était en 2015: Skype chat, Scala.js, les premières rencontres avec l'entreprise dans laquelle il travaillait. Nous avons utilisé Scala avec puissance et j'ai fait la promotion de Scala.js. Je suis allé voir toutes sortes de développeurs JS, dans des podcasts, j'ai parlé de Scala.js et j'ai fait appel à Meetup.

En 2016, nous avons commencé un podcast. J'ai lancé un cri et j'ai répondu à beaucoup de gens. En principe, presque tous sont restés, sauf Taranenko . Puis Grigory Pomadchin et Olya Makhasoeva se sont joints .

- Quelqu'un a-t-il aidé avec les mitaps? J'étais bouleversé quand tu es parti - comme si tout s'était éteint.

Alexey Fomkin : Au sein de l'entreprise, Max Pavlov a aidé. Il sait programmer, mais plus manager. J'ai participé à des présentations, la partie Scala, et Max a aidé à l'organisation: locaux, équipement, inscription.

Tout était parrainé par Data Monsters , alias Flexis, alias Adi Sait - des noms différents à des moments différents. J'y travaillais à ce moment-là. Un autre Meetup que j'ai passé en 2018. Il était seul.

Nikolai Tatarinov: Play Framework, le premier cours et la branche de mitaps de Saint-Pétersbourg

Nikolai Tatarinov est développeur chez SoundCloud, ancien organisateur du SPb Scala Meetup.

Note de l'auteur . Maintenant sur la branche de mitaps de Saint-Pétersbourg . Bien qu'ils aient commencé il n'y a pas si longtemps, 9 événements ont déjà eu lieu. En termes de qualité de la performance, ils ont considérablement élevé la barre: leur chaîne YouTube , les diffusions en direct.

L'un des organisateurs est Nikolai Tatarinov . Bien que maintenant, il a déjà pris sa retraite en raison d'une réinstallation, mais je lui ai posé des questions standard. Nikolay a parlé de l'entrée dans la langue, le mouvement, a légèrement affecté le statut du Play Framework avant la version 2.0 et le sort d' Actor Messaging .

Cadre de jeu

Nikolai Tatarinov : Lors de mon premier emploi en 2012, nous avons utilisé le premier Play Framework. Il a été réalisé à l'image de Rails. C'était intéressant car nous avions une application dans laquelle il était facile de faire des changements. Mais c'était dans un état de prototype - il n'a pas évolué vers une sorte de système de production. Tout y était mélangé - et ça s'est développé.

Le premier framework Play était Java et Groovy. , - — - Python-. , Maven Sbt. — Play Framework Play Framework .

, Play Framework , . — , « ».

Play Framework, , Scala, , — . - Play — . , — , . , . Play Framework , . , .

C Play Framework . , - , Scala . .

2013 — « Secon », . , — , - . , Scala. - , Scala Coursera.

Coursera

« Scala ». , , . , — , , . , , Scala .

Guava 7- Java. : . . , , , .

Scala

: 2014 . , , - Scala. 2015 , Actor . , Dialog , .

— Dialog Actor?

: . , Actor, Dialog. , Actor. , , .

, Actor, . Scala — . , Scala, - , — .

- Scala , — , . - , . , , .

, , . , , Java . — , . , - , . Scala.

, , Scala. SoundCloud. Scala.

: . IT Global Meetup — IT-, 2-3 . . — FProg Spb . : , , , , Coq.

. , Clojure, , — , Coq, , . .

, Scala. IT Global Meetup . , «Java Scala». , . , . , eLama, - , , Scala.

, Scala-, 50. Scala, . 2016 . , , . Slick, , Vodka .

Scala- 2017. , , , . , . . eLama" — .



Meetup DINS. , . — . , Meetup . , , 60-70 — . - .

. . , - . , - Excelsior JET, . , , .


PartialFunction .

« » — eax.me , , Scala 2013 . , , .

ScalaConf 2019 — (15 ) . Scala 26 . , « Hskell», — , Scala. ScalaConf 2019. .