RubyRussia 2019. Nikita Shilnikov sobre efeitos algébricos

Ainda resta muito pouco tempo antes da conferência RubyRussia. Quem não conseguiu o ingresso ainda tem a chance de escolher um dos últimos no site . Nikita Shilnikov na conferência falará sobre efeitos algébricos, mas por enquanto você pode ler a entrevista sobre o tópico do relatório.



Diga-me o que você faz e como ele está conectado ao Ruby?

Trabalho para duas empresas cujos projetos são escritos em Ruby. Em uma das cobranças, podemos dizer que essa é uma semi-empresa e, em outra, criamos um serviço SaaS. Aconteceu que eu faço um monte de código aberto. Há quatro anos, fiquei interessado em um projeto, encontrei falhas de funcionalidade nele, decidi consertá-lo e assim por diante. Agora eu sou um desenvolvedor central de duas organizações e da comunidade. Tudo pode ser visto no meu github . Uma parte do trabalho lida com bancos de dados rom-rb e a outra dry-rb é um conjunto de bibliotecas para diferentes ocasiões.

Seu relatório sobre efeitos algébricos, diga-me quais os benefícios que eles oferecem aos desenvolvedores.

Aqui você precisa de uma pequena entrevista. O ecossistema dry-rb é inspirado na programação funcional. Mas durante o seu desenvolvimento, algo assombrado. Por exemplo, você está desenvolvendo um serviço SaaS e existe uma tarefa simples de isolar dados. Tudo parece estar claro, há algum tipo de serviço, as empresas estão registradas e não devem ter acesso aos dados uma da outra. Você pode resolver de várias maneiras. Mas, de um ponto de vista puramente funcional, não consegui encontrar uma resposta sobre como fazer isso, exceto pela transferência explícita de argumentos em todo o código. Ele apresentou sua solução "não funcional" e morou com ele.

No final de 2018, os ganchos apareceram no React. Quando vi a API deles pela primeira vez, achei impossível fazer essas coisas de maneira tão simples. Eu tenho uma boa idéia de como o JavaScript funciona e decidi que tudo obviamente não está limpo aqui, variáveis ​​globais são usadas ou algo mais. Na minha idéia de como o programa funciona, era impossível ou algum tipo de invasão suja era usada. Eu decidi estudar a questão.

Aconteceu que eu não era a única pessoa interessada neste tópico. Encontrei informações de que existe uma forma de formalização, ou seja, a criação de programas que parecem usar variáveis ​​globais ou algum tipo de condição geral. No entanto, eles ainda estarão limpos. O problema era relevante e comecei a aprofundar. Como resultado, os efeitos muito algébricos se tornaram a resposta. Escrevi um pequeno protótipo em Ruby e, para minha surpresa, funcionou. Implementado na produção, lançado e dirigido por vários meses, depois tomou uma decisão para todos.

Você me intrigou diretamente com os ganchos React. Eu pensei que havia algo muito simples como pilha de chamadas, fechamento, escopo atual.

É mesmo. O problema é que você tem algum tipo de artigo que descreve a semântica e como, do ponto de vista científico, isso deve funcionar. Se você seguir as especificações, parece que você pode criar uma biblioteca. No caso do React, isso também é uma biblioteca ou, digamos, uma estrutura que fornece algum tipo de API. Se você usá-lo corretamente, tudo funcionará bem. Mas se você for para a esquerda ou para a direita, pode terminar mal. No React, eles simplesmente proibiram o uso de ganchos em condições. Eles tiveram que fazer isso. Essa é uma das limitações.

Isso está de alguma forma relacionado à prova matemática da correção do código?

Na verdade não. Não se trata da necessidade de provar algo, a questão está mais na direção da verificação do programa. Os efeitos algébricos são apenas uma descrição da semântica. Nada é provado lá, mas é mostrado como deve funcionar. Se essa biblioteca, que implementa efeitos algébricos, não contiver erros em si mesma, descrevendo a semântica, você garante que seu código funcionará como pretendido.

Como você se sente sobre tipos e linguagens de programação com estaticamente tipadas?

Muito positivo. Por exemplo, temos um back-end no Ruby e um front-end no ReasonML. Isso é OCaml, mas com uma sintaxe diferente. Sendo todas as outras coisas iguais, faço uma escolha na direção desse sistema de tipos. É bastante simples e há várias linguagens nas quais uma implementação semelhante ou semelhante. Quanto mais tipos, melhor. No entanto, estou escrevendo um back-end em Ruby e está tudo bem comigo. Sou o desenvolvedor das ferramentas com as quais trabalho e elas sempre foram sobre tipos: tipos secos, estrutura seca, esquema seco, validação seca, mônadas secas . Trata-se de descrever tipos que vêm do banco de dados, do usuário, de sistemas externos. Então você sempre sabe o que o código Ruby funciona para você. Mesmo que não seja digitado por si só, você pode ter certeza do tipo de variável com a qual está trabalhando.

Existem rumores de que haverá tipos no Ruby 3. O que você diz sobre isso?

Eu tenho experiência com Python. Quando os tipos foram trazidos para lá, o tuling não era muito desenvolvido e eu não fiquei impressionado. Agora a situação é melhor lá. Você pode ir lá e descrever tudo com tipos e aplicar algum tipo de ajuste, que verificará se o seu programa está correto. É sobre algum tipo de substituição do compilador, sobre o que o sorvete está fazendo agora. Isso levou vários anos para o Python. Eu sempre aprecio o movimento em direção aos tipos, mas não tenho ilusões.

Procurando uma nova sintaxe que você planeja implementar em termos de código Ruby?

Especialmente não jogou, entrou no chat, olhou. Mas não tenho opinião sobre como vale a pena implementar. A sintaxe pode ser melhorada, alterações no idioma e assim por diante. Agora eles criaram a sintaxe usual compatível com Ruby. Eu não acho que a sintaxe seja uma pedra de tropeço aqui, uma pedra de tropeço está afinando e, como eu disse, esse é um caminho muito longo.

O que mais você gostaria de ver em Ruby, como você vê o seu desenvolvimento?

Eu estaria interessado em multitarefa cooperativa. Já temos multitarefa cooperativa na forma de fibra. Ainda não temos a capacidade de executá-los em vários threads. Existem opções de como isso será feito e não está claro de que forma. Dado que Ruby, a implementação C tem um legado bastante sólido, Matz não quer quebrar a compatibilidade com versões anteriores. Estou inclinado a uma combinação de fibras e vários fios correndo simultaneamente. Talvez algo como Guild funcione.

Este ano, Yukihiro Matsumoto, autor de Ruby, chega à conferência. O que você gostaria de discutir com ele tomando uma xícara de café ou um copo de saquê na festa?

A melhor coisa que podemos fazer na comunicação com os autores de idiomas ou mesmo de bibliotecas é mostrar a eles como usamos esse produto na vida real. Além disso, mesmo como os autores não esperavam. Isso dará ao autor a oportunidade de levar em conta essa experiência e aplicá-la em um maior desenvolvimento. Eu gostaria de mostrar toda a história com efeitos algébricos. Eu diria - veja, o que uma coisa pode ser feita na linguagem milagrosa que você criou. E talvez depois disso ele venha com outra coisa para nós.

Vejo você no RubyRussia!

Lembre-se de que a conferência já é neste sábado, as inscrições ainda estão abertas.

Não haverá apenas relatórios, mas também estandes das melhores empresas:

Organizador - Evrone
Parceiro Geral - Toptal
Parceiro Gold - Gett
Parceiros Silver - Valarm , JetBrains , Bookmate e Cashwagon
Parceiro Bronze - InSales