Corda: Kotlin

Quando alguém olha para o código Corda , imediatamente percebe que ele está escrito no Kotlin - a nova linguagem de programação do JetBrains, que pode ser compilada para JVM e Javascript. Foi uma escolha incomum e, neste artigo, quero compartilhar alguns motivos para essa decisão e a experiência do nosso "ano em produção da Kotlin".

Por que Kotlin?

Esta solução pode ser dividida em duas partes:

1. Qual plataforma usar? JVM, .NET, Nó, Python / Ruby, Go, Haskell ou algo compilado (em código de máquina)?
2. Qual idioma usar se você escolher a JVM? Java? Se não, então por quê? E se não, então o que mais: Scala, Ceilão, Clojure, Kotlin, Python, Ruby, Javascript ou Haskell (porque todos eles têm uma implementação para JVM).

Os motivos para a escolha da JVM como plataforma são bem conhecidos no ambiente de aplicativos corporativos e há pouco motivo para isso. Basta dizer que, se você precisar de um tempo de execução escalável, seguro para threads e de plataforma cruzada com coleta de lixo e com muitas bibliotecas bem documentadas que resolvem problemas básicos de negócios, a escolha será reduzida apenas para JVM e .NET.

No início dos trabalhos em Corda, o projeto não tinha nome e era difícil imaginar que no futuro ele se tornaria um produto. De fato, quando o projeto, que se tornou Corda, começou em dezembro de 2015 (no meu primeiro dia de trabalho), não havia nenhum plano para criar um novo sistema corporativo de contabilidade distribuída. Corda começou como um conjunto de protótipos para explorar novas idéias e requisitos nos quais o Grupo de Trabalho de Arquitetura do Consórcio estava interessado, especialmente aqueles relacionados à visibilidade limitada dos dados e ao modelo de dados que fornece a escalabilidade do "conjunto de matrizes de saída transacional UTXO" juntamente com a programabilidade dos contratos inteligentes imperativos da Ethereum em geral.

Devido ao fato de não estar claro se esses protótipos se transformariam em algo ou simplesmente serviriam de informação para outros produtos no mercado, enfrentamos uma escolha difícil. Por um lado, queríamos explorar rápida e produtivamente algoritmos e estruturas de dados. Por outro lado, deve haver uma oportunidade potencial para criar um grande produto corporativo e contratar pessoas rapidamente para ele.

Java definitivamente atendeu a esses requisitos, mas a falta de recursos modernos na linguagem reduz significativamente a produtividade e, mais implicitamente, o moral dos desenvolvedores.

A digitação dinâmica não foi considerada - os benefícios da correção, das ferramentas de desenvolvimento e do desempenho fornecidos pela digitação estática são grandes demais para serem negligenciados.

Idiomas fundamentalmente diferentes dos mais populares também não foram considerados, porque queríamos contratar especialistas financeiros. E, embora seja inteiramente possível criar uma equipe em torno de um idioma como Haskell, encontrar uma pessoa com séria experiência bancária e idiomas preguiçosos (preguiçosos) puros (funcionais) que moram aleatoriamente em Londres parecia arriscado. Além disso, a própria natureza do produto implicava que nossos "usuários" são na verdade desenvolvedores de plugins e aplicativos que usam a plataforma, e não faz sentido exigir que eles aprendam paradigmas e ferramentas completamente novos. Nossa escolha de idioma não deve limitar muito os usuários.

Como resultado, esses requisitos nos deixaram com Kotlin, Scala e Ceilão. Essas línguas são bastante semelhantes e bastante interessantes. Escolhemos o Kotlin pelos seguintes motivos:

• Integração quase perfeita com Java
  
  • Em particular, os programas Kotlin usam uma versão aprimorada (aprimorada pelo compilador) das coleções JDK padrão, o que garante que não haja problemas de integração devido ao uso de outras bibliotecas de coleções. Nós transmitimos e recebemos coleções de e para bibliotecas Java em todos os lugares, por isso é importante que isso não cause problemas.
  • Nas classes Kotlin, obtemos uma API Java de aparência simples com os métodos get / set / is acordo com os tipos. Nenhuma anotação especial ou outras ações são necessárias para isso. Pelo motivo que o Corda fornece uma API projetada para uso transparente pelos desenvolvedores Java, esta é uma grande vantagem: do código comum, você obtém uma API que não pode ser distinguida da API Java com apenas algumas ressalvas (por exemplo, a interceptação explícita de exceções verificadas do Java requer explícitas anotação de método)
• A inclusão de pequenas funções como map / filter / fold / groupBy (em vez de esperar que a JVM faça isso sozinha) é feita pelo compilador. Infelizmente, o compilador JIT JVM, embora excelente em geral, não elimina em todos os casos a sobrecarga do uso abundante de funções de ordem superior. O uso do Kotlin compensa isso, além de permitir que você controle a execução do programa a partir das funções lambda (nota: por exemplo, retorno não local ). Esse é um dos recursos pouco conhecidos, mas ao mesmo tempo úteis. Porque em todos os lugares em que escrevemos código com um estilo tão funcional, se ele foi mal traduzido em código de máquina, poderíamos criar problemas de desempenho para nós mesmos.
• Devido ao fato de o código no Kotlin ser traduzido em um código Java bastante semelhante, quase todas as ferramentas orientadas a Java existentes funcionam imediatamente. Isso nem sempre é verdade no caso de outros idiomas. Por exemplo, o Quasar tem dificuldade em instrumentar o código Scala porque precisa de anotações de método, e Scala converte lambdas em métodos que não podem ser anotados. As lambdas Kotlin geralmente são incorporadas (veja acima) ou podem ser anotadas de outra forma.
• Excelente documentação e uma pequena biblioteca padrão tornam o aprendizado muito rápido. Não indicamos em nossas vagas a necessidade de experiência em Kotlin, e contratamos pessoas sem o seu conhecimento, dando de 1 a 3 anos após os quais um novo membro da equipe conseguiu escrever código idiomático.
• Com base na seleção de candidatos que nos entrevistaram, o IntelliJ é o IDE mais popular (eles tinham uma escolha livre de ferramentas). Entre as linguagens pós-Java, o IntelliJ suporta o Kotlin, o melhor de tudo.
• Eu já tinha uma experiência satisfatória com ele e, portanto, tinha certeza de que seus novos colegas também gostariam dele.

Se não fosse o Kotlin, provavelmente escolhemos o Scala: o Kotlin é amplamente inspirado por ele e ambos são bons idiomas.

Nosso ano com Kotlin

Como é - um ano para trabalhar com um novo idioma no contexto de um aplicativo corporativo?

O mais importante foi, sem dúvida, ouvir dos colegas que eles realmente gostam de trabalhar com ele. A linguagem de programação é uma questão pessoal para todos, e as pessoas geralmente têm uma opinião definida sobre esse assunto. Se você, como a primeira tarefa de um novo emprego, pedir a alguém para aprender um novo idioma e nem avisar sobre isso com antecedência, sempre haverá o risco de um colega simplesmente odiá-lo e considerá-lo irritante em vez de aumentar sua produtividade. Mas esse não é o caso.

A seguir, estão alguns dos problemas que geralmente aparecem em um ambiente de desenvolvimento corporativo pós-Java / C # que nós mesmos encontramos:

• O código parece diferente dependendo de quem o escreveu. Em geral, não é um problema tão grande. Ao contrário do Go, que requer um certo estilo de design, o código Kotlin de diferentes autores pode parecer diferente. Mas o IntelliJ possui uma ferramenta de formatação que fornece um estilo de base de código unificado. É mais limitado do que para Java, mas é o suficiente. Um problema mais sutil, especialmente com o código Scala, é a oposição do estilo de codificação Java-OOP e Haskell-FI. O código Scala que usa bibliotecas como o scalaz pode ser difícil de ler para desenvolvedores que esperam ver o Java aprimorado . Nesse debate, o Kotlin está firmemente do lado do Java aprimorado . E, embora a programação funcional, de certa forma, possivelmente em Kotlin, a comunidade (pelo menos por enquanto) não tenha se dividido em campos. Tivemos casos em que o código foi escrito como se fosse Haskell, mas foi elaborado na revisão de códigos.
• Bibliotecas Em Corda, usamos mais de 50 bibliotecas de código aberto e não houve problemas com nenhuma. Nunca escrevemos invólucros ou camadas de adaptadores. Como sistemas de construção em projetos no Kotlin, Maven ou Gradle são geralmente usados ​​- não há substituição oficial específica do Kotlin para essas ferramentas (embora a Gradle tenha introduzido o suporte ao Kotlin como uma nova linguagem de script!).
• DSL e SQL. C # possui LINQ, Java possui JOOQ e Kotlin tem Exposed . Essa é uma das áreas em que o Kotlin é um pouco mais fraco que seus concorrentes - Exposed é um ótimo exemplo do uso dos recursos do Kotlin na criação de DSL, mas a própria biblioteca possui uma API instável e é um projeto secundário. JOOQ, é claro, pode ser usado com Kotlin e, olhando para trás, essa parece ser a opção preferida.
• IDE / kit de ferramentas. O plugin Kotlin para IntelliJ é, é claro, escrito por JetBrains e, em geral, é ótimo. No entanto, é menos sofisticado quando comparado ao suporte a Java. Novos recursos do editor, como uma dica de parâmetro , devem ser portados manualmente para o Kotlin, e o próprio suporte, como tal, geralmente fica atrás dos plug-ins Java muito mais antigos. Também observamos que o plug-in do IDE frequentemente notifica erros internos, embora a frequência das exceções do IDE tenha diminuído significativamente durante o ano (e parece que elas não afetam nada). O uso de outras ferramentas também não causa problemas, porque o que é escrito para Java geralmente funciona imediatamente . Uma exceção são as ferramentas que funcionam com o código-fonte em vez do bytecode e que, obviamente, não podem ser reutilizadas. Com tudo isso, o compilador Kotlin e o plugin IDE não são tão depurados como no caso de Java, mesmo um ano após o lançamento da 1.0. Provavelmente você nunca encontrará erros internos no javac , mas, embora muito raramente, ainda os vemos no Kotlin.
• Reconhecimento pelos usuários. Os usuários de corda são geralmente instituições financeiras grandes e conservadoras. Essas empresas preferem usar idiomas comuns e bem estabelecidos. Kotlin, não sendo um nem o outro, claramente causou alguma surpresa no momento em que começamos. "Por que Kotlin?" - Essa é uma pergunta que, no último ano, praticamente desapareceu, porque as pessoas examinaram mais de perto e perceberam que isso não é tão arriscado quanto é o caso das novas linguagens de programação. Também tentamos facilitar a adoção, fornecendo exemplos de código que demonstram que a criação de aplicativos usando a plataforma não requer conhecimento da Kotlin. Os resultados não foram tão bem-sucedidos - muitos desenvolvedores que trabalham pela primeira vez com o Corda ainda começam a explorar o Kotlin. Não está muito claro se esse é o resultado do fato de termos fornecido exemplos e documentação de uso insuficientemente orientados para Java ou se isso é apenas uma boa desculpa para aprender uma nova ferramenta interessante. Também fomos ajudados pela crescente adoção do Kotlin nos principais bancos de investimento. Ao longo do ano passado, ouvimos de vários membros do consórcio que suas equipes de desenvolvimento interno começaram a examinar seriamente o Kotlin em busca de seus próprios produtos: geralmente impulsionados pela disponibilidade de ferramentas que convertem Java em Kotlin, que fornecem uma integração significativamente menos dolorosa à base de código existente.
• Suporte comercial. O risco de usar linguagens pouco conhecidas é que elas podem parar de desenvolver ou ter objetivos que não são consistentes com as necessidades formadas em torno do produto, a comunidade de usuários (por exemplo, no caso de linguagens de pesquisa, o principal objetivo dos desenvolvedores é criar artigos científicos). A principal razão pela qual nos sentimos confiantes com a Kotlin é que a JetBrains é uma empresa estável e lucrativa, que está no mercado há mais de 15 anos. O JetBrains rapidamente começou a provar sua própria ferramenta, introduzindo o Kotlin no código dos principais produtos. Assim, o risco de rescisão do suporte é bastante pequeno. Além disso, o JetBrains já é uma empresa de meia idade e seu mercado-alvo (IDE e ferramentas de desenvolvedor) deixou de ser novo ou especialmente na moda, o que reduz o risco de uma possível aquisição da empresa, o que pode levar a mudanças estratégicas imprevisíveis. E, apesar da falta de um pacote de suporte comercial para Kotlin, na prática, a equipe corrige rapidamente problemas conhecidos. No momento, o JetBrains pretende lançar a próxima atualização de idioma após um ano desde o lançamento 1.0. Esse ciclo de lançamento é bastante semelhante ao ciclo de desenvolvimento no ambiente corporativo.

Conclusões?

Não lamentamos: a escolha de um idioma jovem no início deste projeto foi, embora um risco, mas equilibrada. Ele fez um bom trabalho para nós e não mudaríamos nossa escolha.