Seguindo os passos do movimento russo Scala. Parte 3

Esta é a parte final da investigação do movimento Scala na Rússia. Na primeira parte, aprendi com Roman Grebennikov sobre o Voronezh beau monde, C ++ e Erlang, e com Roman Timushev sobre o primeiro Akka e o nascimento das reuniões em Moscou. Na segunda parte, conversei com Alexander Podkhaluzin e Mikhail Mutsyanko : conhecer Scala, 2007, Scala Days, Scala Native, mudar para Kotlin, que Scala é bom para bancos, os primeiros eventos em São Petersburgo, Eclipse, Jason Zaugg, IDE e Scala Plugin.



Durante a preparação da segunda parte, Vladimir Uspensky ( vuspenskiy ) me indicou Alexander Podkhalyuzin , com quem gravamos uma grande entrevista. No dia seguinte, recebi uma mensagem de Vladimir, mas agora com sua história pessoal: Qiwi, Scala em Tinkoff, primeiras reuniões, links para blogs antigos (agradecimentos especiais por isso) e funcionalismo de 2008 de Rúnar, que roda em Java, - ainda é sangue dos olhos, pelo menos incomum. Além disso - as histórias de Roman Elizarov , Alexei Fomkin e Nikolai Tatarinov . Características da contratação de desenvolvedores Scala, cursos sobre o Coursera, “código perfeito”, compilação “demoníaca”, design em Kotlin, 10.000 linhas de código, Tinkoff Internet banking, novamente Tinkoff, Play Framework, faleceu nas reuniões Flash, “Sunrise” e São Petersburgo - sobre tudo isso na parte final da trilogia sob o corte.

Vladimir Uspensky: Coursera, Tinkoff e recursos de contratação para Scala

Vladimir : Naquela época, eu trabalhava na Qiwi e refatorava muito código Java, mas ainda assim eu recebia muita água e um clichê. Fiquei atormentado, mas de alguma forma me humilhei.

Depois de algum tempo, fui aos blogs de Alexander Temerev e Vlad Patryshev . Vlad estava na vanguarda na implementação de Java, pelo que entendi. Eu li sobre Scala com eles, comecei a notar menções de construções estranhas para mim, como opções em Java . Até lancei essa opção em algum lugar da produção. Havia mais manipulação exótica de erros preguiçosos em Java e paralelismo Java de ordem superior por Rúnar Bjarnason . Tudo isso explodiu o cérebro infernalmente e ficou imaginando como aplicar tudo.

Quando estudei exemplos específicos, por exemplo, de Daniel Spiewak : Scala para Java Refugees , era exatamente isso que estava faltando. Toda a água e estranhas inconsistências como `_` vs `*` vs `?` Do código Java se `_` vs `*` vs `?` , e a essência permanece.

Era o Scala 2.7 e, para dizer o mínimo, não era estável. Muitos projetos tentaram isso para testes de unidade ou classes de casos. Para adicionar Scala a um projeto Java, você precisava configurar a compilação conjunta no Maven . Mas decidi tentar adicionar suporte a um projeto não crítico em Qiwi. Tudo funcionou - fiquei muito feliz, mas foi aí que acabou.

Trabalho na implementação de Tinkoff e Scala

De repente, fui convidado para Tinkoff para liderar o desenvolvimento de um novo banco na Internet, que foi totalmente desenvolvido dentro da empresa. No começo, descobri as tarefas atuais, mas quando cheguei ao back-end, percebi que era hora de implementar o Scala.

Acabou de sair o Scala 2.9 com sintaxe moderna, na época. Coleções paralelas na moda eram perfeitamente adequadas para executar algo rapidamente em paralelo, se os detalhes não fossem importantes. E o criador do Groovy James Strachan publicou : "Posso dizer honestamente que se alguém tivesse me mostrado o livro da Programming Scala de Martin Odersky, Lex Spoon & Bill Venners em 2003, eu provavelmente nunca teria criado o Groovy".

Outro fator na escolha do Scala é que todas as pessoas que trabalharam em ferramentas, linguagem, bibliotecas ou escreveram sobre o Scala eram super inteligentes e enérgicas. Portanto, havia confiança de que essa era a escolha certa para o futuro.

Enquanto trabalhava no banco, comecei a ir a conferências estrangeiras. Os primeiros Scala Days em 2012, o nerd flatMap em Oslo. Naquela época, conheci Zhenya Burmako . Agora, às vezes, passeamos pelo oceano já aqui na Califórnia.

Contratação de desenvolvedores da Scala

Gradualmente escreveu um banco online. Em 2012, ele se tornou o melhor da Rússia, de acordo com a Global Finance . Para mim, esta é uma confirmação da afirmação “Faça normalmente, será normal”, e não algo extraordinário.

Oleg Tinkov promoveu o tópico do banco, o que foi engraçado. Talvez isso tenha nos ajudado a contratar bons desenvolvedores - as pessoas estavam na equipe, mas eu queria expandir. Primeiro, escrevemos na vaga "programador Java, Scala - plus". Mas mencionar Java em trabalhos para desenvolvedores Scala interrompe as pessoas que não querem ter nada a ver com Java. Portanto, alteramos a vaga para Scala Senior Developer. Isso me permitiu contratar dois caras com quem eu gostaria muito de trabalhar um dia.

Grupo no Facebook

Eu queria entender quem, em geral, na Rússia e Moscou, também estava interessado de forma independente em Scala e que tipo de pensamento a comunidade tinha. Não houve reuniões ou bate-papos, e a ideia era reunir todos. Ele fez um grupo no Facebook , no qual planejamos as primeiras reuniões. O que é uma reunião sem um grupo no Meetup ? Fui criar, mas o grupo já existe - Roman Timushev criou. Decidimos juntar forças e adicionamos Misha Aksarin .



A primeira reunião foi realizada sob o pretexto de um curso Scala sobre programação reativa no Coursera . Muitos espiaram, mas cerca de 20 pessoas vieram: eles se conheceram, disseram quem estavam fazendo e estavam interessados, discutiram os exercícios do curso e concordaram em se reunir novamente.

Então começou.

Roman Elizarov: 10.000 linhas sobre Scala, perfeccionismo e compilação impiedosa

Roman Elizarov ( elizarov ) - líder do grupo JetBrains, participou de trabalhos sobre corotinas e bibliotecas em Kotlin.

Nota do autor . Antes de gravar a entrevista, pensei que seria um desastre se eu as pegasse apenas de pessoas envolvidas em Scala. "Adoração" contínua ou, pior, "erro do sobrevivente". Portanto, decidi que definitivamente acrescentaria uma mosca na pomada.

Isso é mais difícil: pessoas com experiência real que, por algum motivo, não entraram no idioma são uma ordem de magnitude menor do que os que não têm experiência no Scala. Mas então me lembrei do cargo de Roman Elizarov ( elizarov ) - o líder do grupo JetBrains - em que ele rabiscou no Scala entre os casos, o que causou vários esgotamentos, incluindo o meu. Apesar do negativo, é improvável que Roman tenha publicado um post sobre alguns rumores sobre o idioma. Deve haver uma razão, algum tipo de experiência negativa do uso - acabou desse jeito. Abaixo, a entrevista com ele é sobre isso e algumas discussões sobre o design e a conexão da corotina com o Scala CPS Plugin.

Caso em 2010

Roman Elizarov : Por volta do ano 2000, programei todos os tipos de enterpases em Java. Portanto, segui os idiomas da JVM, incluindo o Scala. Parece que a primeira vez que li sobre o idioma por volta de 2005-2006.

Quando você lê abstratamente, a sintaxe é bem legal. Lembro-me de ler a descrição, brincar e gostei muito de tudo. Muitas coisas em Java, detalhadas e difíceis de trabalhar, são fáceis de fazer no Scala. Tudo isso me interessava já, então, não do ponto de vista do FP, mas do pragmático - enquanto escrevemos o código. Mas, como a base de código Java já é grande, um monte de classes atuais, não foi possível usá-la na prática até que a história aconteceu em 2010.

Em 2010, nossos parceiros dos Estados Unidos, da empresa, ficaram entediados. Eles queriam novidade e escreveram um novo subsistema inteiramente em Scala. Ele tinha algum tipo de interface web, ele estava fazendo algo simples. Ao mesmo tempo, esse não é o Play Framework - apenas um serviço da Web recebido solicitações de usuários, chamado API Java. Um site normal para executar algum tipo de funções interativas internas. Parceiros cortar, funcionou com sucesso, está tudo bem.

Naquela época, éramos seus contratados. Os desenvolvedores do subsistema jogaram o suficiente e decidiram fazer outras coisas. Nossos clientes vêm até nós e dizem: “Pessoal, aceitam isso? Ela usa sua API de qualquer maneira. Ótimo, aqui está - uma maneira real de experimentar o Scala. Então ninguém nos permitiria programar em Scala, porque tudo é difícil, mas como já existe um projeto, esse é o motivo. Esta é, de fato, a primeira experiência de produção com a Scala.

A primeira impressão do Scala é como o código é compacto do que em Java . Scala permite escrever coisas complexas de forma compacta. O subsistema recebeu aproximadamente 10.000 linhas de código, mas em Java seria necessário o dobro por causa das classes. A sintaxe, todos os objetos internos para transferência de dados, até toda a adaptação da API Java são compactos.

Primeira e última 10.000 linhas no Scala

Quando os desenvolvedores saíram, eles deixaram o código desmontado - no sentido de que era apenas código . Tentamos pegar o suporte, mas havia um problema - a compilação.

Compilar código Scala é uma missão. O código é compilado apenas com uma versão específica do Scala Compiler - precisa para a versão do ponto, para a versão do patch. Uma versão maior ou menor não é mais compilada .

Isso decidiu para mim em 2010 o destino da Scala na empresa, onde existem milhões de linhas de código. É assustador imaginar como viver se você alterar a versão secundária do compilador e não quiser.

"Você não se lembra exatamente por quê?"

Roman Elizarov : Por que estava desmoronando, não me lembro, é claro. Algo estava mudando constantemente de versão para versão. Talvez estivéssemos na hora errada?

Mas continuei monitorando o desenvolvimento do Scala, apesar de apenas na empresa não implementá-lo. Como resultado, a funcionalidade foi transferida para outros aplicativos Java. Neste Scala nesta empresa deixou de existir.

Essas 10.000 linhas foram as primeiras e únicas. O código funcionou por muito tempo na produção, mas depois foi analisado por outros serviços e eliminado.

Especificamente para minha atividade profissional, essa experiência deixou uma marca indelével, no sentido de que, no entanto, é necessária a compatibilidade de tudo isso. Agora eu estou fazendo Kotlin. Não é de surpreender que simplesmente gastemos uma quantidade irreal de tempo e forças adicionais para garantir a compatibilidade de tudo e de tudo. Às vezes, uma quantidade considerável de tempo não entra em funcionalidade, mas simplesmente para que tudo seja compatível. Em particular, minha experiência passada afeta isso.

Ainda me lembro constantemente do Python. Em relação à compatibilidade, temos dois erros: Scala e Python. Quando se trata de compatibilidade, ninguém quer repetir a transição de 2 para 3 Python, e ninguém quer ser como o Scala.

"Código perfeito"

- Muitas vezes você quer refazer algo para que tudo seja "chocolate"?

Roman Elizarov : Estou envolvido em design e quero refazer constantemente tudo . Eu nunca gostei do que fiz. Enquanto estou preparando algo para o lançamento, encontro algumas coisas que quero mudar. Assim que não lançamos algo, já vejo as falhas: ainda não foi concluído, aqui temos que reescrevê-lo do zero. Mas este é o caminho para lugar nenhum. Existem apenas duas abordagens: ou melhorarei o código indefinidamente e nunca chegarei ao lançamento, ou lançarei o lançamento e ele se tornará Legado. Você não pode liberar o código perfeito .

Em seguida, passo metade do tempo aprimorando o produto e o segundo em compatibilidade com o que já foi lançado. A experiência ajuda a "pôr canudos" com antecedência. Vejo que terei que refazê-lo em breve e gastar muito tempo no momento do lançamento na rede de segurança, antecipando mudanças futuras. Obviamente, fazer algo do zero e não se preocupar com compatibilidade é muito mais fácil. Mas o compromisso é que você faz isso perfeitamente ou eles usam o seu produto. Um exclui o outro.

Design na Kotlin

Roman Elizarov : Eu sempre segui o Scala, porque quando projetamos algo no Kotlin, estudamos o que outras línguas têm, incluindo o Scala. Há cerca de dois anos, desenvolvemos corotinas Kotlin. A principal "inspiração" é, obviamente, o C #. Tudo começou com ele e de lá já nasceu, só isso. Então começamos a estudar Go.

Quando o design começou a se desviar do C # e “continuações” apareceram e depois “continuações delimitadas”, começamos a estudar outros idiomas mais uma vez. No Google, eu me deparo com Scala - acontece que já havia " continuações delimitadas ".

- Você está falando do Compiler Plugin?

Roman Elizarov : Sim. Ao mesmo tempo, o design era fantasticamente semelhante ao que está agora em Kotlin. É claro que há uma diferença sintática: no Kotlin, escrevemos o modificador de suspensão no início e, no Scala, você escreveu a anotação csp no valor de retorno. Mas qual é a diferença de onde colocar o modificador: no tipo de valores de retorno ou no começo?

O design em Scala era muito semelhante ao atual em Kotlin. Fiquei interessado - como é que, como um design tão legal, por que não voou? Por que ninguém escreve assim na Scala moderna? Eles me mostraram como escrevem no Play Framework - não há plug-in por lá.

Todo mundo escreve futuros, e tivemos uma ótima idéia de nos livrar dos futuros, porque esse design é mais conveniente. E assim aconteceu em Kotlin: o futuro não é necessário, existem corotinas. Em Scala, eles abandonaram as "continuações" e não voaram. Porque

A falta de sentido e crueldade da compilação

No processo de busca, encontrei o anúncio mais original. Naquele ano, "continuações delimitadas" apareceram em Scala. Em Scala, tudo foi feito da mesma maneira que agora em Kotlin.

O anúncio neste sentido é indicativo. Ele dizia: "Nós fizemos" continuações delimitadas ", veja, podemos escrever as mesmas coisas legais que no Lisp". Por exemplo, pegamos um exemplo no Lisp das obras dos anos 80 e 90 e o reescrevemos no Scala: as listas estão ancoradas, aqui “shift / reset”. No Lisp e em idiomas semelhantes, existe uma construção para continuações delimitadas , designada como "shift / reset". O nome explode o cérebro - ninguém sabe o que é mudança / redefinição. Nem quem estudou Lisp, nem quem nunca o conheceu.

O principal neste anúncio são comentários como este: “Isso não faz sentido. Passei algum tempo na Wikipedia e em alguns outros lugares para tentar entender isso. Na minha perspectiva, essas são formas complicadas de adicionar números e não tenho idéia do que está sendo ganho ou realizado. " Eles explicam a essência do post.

Portanto, esse anúncio de um recurso importante é absolutamente inútil. Se for lido por uma pessoa que escreve o código do aplicativo, ele não receberá uma resposta para a pergunta: “Por que eu preciso disso? Que problema ele resolverá? ”O autor não levantou essa questão. Portanto, o recurso não voou - não porque era ruim, mas porque não havia tarefa para voar .

"Ela foi mal aplicada?"

Roman Elizarov : Sim, eles arquivaram errado. Era como se anunciado, mas eles não explicaram por que era necessário e quais problemas ele poderia resolver. Mas o assunto não é "retidão" ou beleza. A propósito, nós da Kotlin também não sabemos como escrever lindas postagens de blog, mas escrever uma postagem adequada não é suficiente para escrever um belo anúncio. A apresentação correta não é tanto uma explicação do porquê, mas também uma explicação do ponto de vista da API .

Eu li o código e lá os métodos shift / reset são usados. Por que foi chamado shift / reset nos anos 70? Tentei encontrar o autor do nome do passado, mas não consegui. Apenas alguém veio com esse nome. Para um programador moderno, essas palavras não dizem nada. Eles não significam nada.

Lido tanto com as corotinas que parece que devo saber tudo sobre elas, porque leio vários artigos científicos. Mas quando vejo um código que usa “shift / reset”, eu me esforço toda vez para entender o que está acontecendo lá e por que é necessário. Parece algum tipo de magia negra, embora sem sentido.

Alexey Fomkin: o falecido Flash, Voskhod e os primeiros encontros em Moscou

Alexey Fomkin ( yelbota ) - programador, palestrante, podcast, colaborador de código aberto, entusiasta do Scala.

Nota do autor . Depois de se afastar dos assuntos de Timushev e Uspensky , todo o movimento em Moscou repousou em Alexey Fomkin . Além disso, ele lançou o podcast Scalalaz e olhou para outros podcasts: DevZen , Debriefing , Remote Talk . Ignorá-lo nesta série de artigos seria um grande erro.

Da sua empresa a um desenvolvedor Scala

Alexey Fomkin : Eu provavelmente ficarei muito entediado - não havia nada de interessante. Eu tenho minha história pessoal. É interessante para mim, mas para os leitores pode ser chato.

Na verdade, participei do Action-Script e, mais tarde, tive meu próprio negócio. Quando os negócios fecharam, fiquei sem tudo, porque o Flash já havia morrido. Consequentemente, não havia mais nada no meu currículo. Eu estava procurando trabalho, fiquei emocionalmente deprimido porque perdi tudo.

Eu não me via como diretor técnico, nem mesmo como líder de equipe. Após um fracasso com sua empresa, havia apenas ambição para um programador comum. Tentei obter um desenvolvedor JS no Yandex. Mas eles me recusaram porque eu não o conheço bem - o que era verdade, é claro.

Então pensei em Scala. Eu tentei várias vezes, a partir de 2010 - eu gosto do idioma. Eu tentei porque no escritório em que trabalhei em 2010, havia Oaml. Eu queria, como o OCaml, apenas ter uma JVM - gostei. Por outro lado, escrevi vários projetos no Scala e, em 2014, comecei a aplicar na minha empresa.

Havia uma idéia para avançar em direção ao Scala: existem muitas ofertas, muitos projetos e os desenvolvedores estão em falta. Então eu fiquei tenso e em poucos meses puxei e atualizei todo o meu conhecimento. Tive sorte - consegui um diretor técnico e digitei a equipe Scala.

Voskhod, bate-papo via Skype e organização das primeiras reuniões

Ao mesmo tempo, pensei que deveríamos tentar estimular algumas coisas, até que o assunto não seja muito desenvolvido na Rússia. Ele conversou com Uspensky , Timushev e Askarin . Aconteceu que Askarin foi deixado sozinho - Uspensky estava "nas malas". Eu falei sobre fazer um Meetup ou não. "Sim, nós somos." E este foi o último mitap que a equipe antiga organizou. Foi em alguma instituição estatal, o Instituto de Pesquisa “Voskhod” .Fui lá, contei sobre o Scala JS ou algo assim, e então esse tópico desapareceu completamente. Como tudo é tão ruim e não há atividade, decidi organizar tudo sozinho - comecei a me tornar ativo em um bate-papo do Skype, no qual as montanhas rochosas estavam saindo.

- Quantas pessoas estavam lá?

Alexey Fomkin : Não me lembro - não há muitos deles no bate-papo moderno. O principal backbone é de 10 a 50 pessoas que estão constantemente conversando. O resto vem, vai, faz perguntas - como agora.

Era 2015: bate-papo no Skype, Scala.js, as primeiras reuniões com a empresa em que ele trabalhava. Usamos o Scala poderosamente e eu promovo o Scala.js. Fui a todos os tipos de desenvolvedores de JS, em podcasts, conversei sobre o Scala.js e liguei para o Meetup.

Em 2016, iniciamos um podcast. Eu chorei e respondi a muitas pessoas. Em princípio, quase tudo ainda restava, exceto Taranenko . Então Grigory Pomadchin e Olya Makhasoeva se juntaram .

- Alguém ajudou com os mitaps? Fiquei chateado quando você foi embora - como se tudo tivesse desaparecido.

Alexey Fomkin : Dentro da empresa, Max Pavlov ajudou. Ele sabe como programar, mas mais gerente. Eu estava envolvido em apresentações, a parte Scala, e Max ajudou na organização: instalações, equipamentos, registro.

Tudo foi patrocinado pela Data Monsters , também conhecida como Flexis, ou Adi Sait - nomes diferentes em momentos diferentes. Eu estava trabalhando lá naquele momento. Outro Meetup que passei em 2018. Ele estava sozinho.

Nikolai Tatarinov: Play Framework, o primeiro curso e o ramo de mitaps de São Petersburgo

Nikolai Tatarinov é desenvolvedor do SoundCloud, ex-organizador do SPb Scala Meetup.

Nota do autor . Agora, sobre o ramo de mitaps de São Petersburgo . Embora tenham começado há pouco tempo, 9 eventos já ocorreram. Em termos de qualidade do desempenho, eles aumentaram muito o nível: seu canal no YouTube , transmissões ao vivo.

Um dos organizadores é Nikolai Tatarinov . Embora agora ele já tenha se aposentado devido à realocação, eu vim até ele com perguntas padrão. Nikolay falou sobre a entrada no idioma, o movimento, afetou levemente o status do Play Framework antes do lançamento 2.0 e o destino do Actor Messaging .

Estrutura de jogo

Nikolai Tatarinov : No meu primeiro emprego em 2012, usamos o primeiro Play Framework. Foi feito à semelhança do Rails. Foi interessante porque tínhamos um aplicativo no qual era fácil fazer alterações. Mas estava em um estado de protótipo - não evoluiu para algum tipo de sistema de produção. Tudo foi misturado lá - e se desenvolveu.

O primeiro Play Framework foi Java e 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. .