Trocando Ruby por Kotlin — Parte 2

Esse é o segundo de uma série de 3 posts que foram escritos de forma colaborativa por Fabrício Rissetto, Matheus Caceres e Murilo Capanema. Não deixe de conferir as partes 1 e 3.

Início do estudo de novas linguagens

Com a constante oferta e evolução de linguagens de programação e seus ecossistemas no mercado, opção é o que não faltava. Várias linguagens atendendo a vários propósitos. Qual deveríamos escolher? Começamos olhando pra 4 candidatas: C#, Scala, Java e Kotlin.

C# e .NET

O ecossistema .NET tem evoluído rapidamente nos últimos anos e sua comunidade é uma das mais influentes em DDD, tendo muito código fonte com exemplos, libs e literatura a respeito. O Entity Framework possuía a implementação mais próxima do que estávamos buscando, pois a implementação do padrão de repositórios com ele é muito simples, permitindo o uso de fluent mappers e desacoplando totalmente as classes de domínio das questões de persistência. Essas qualidades nos chamavam muita atenção, entretanto, estávamos também em um movimento de começar a migrar nossas aplicações para uma estrutura mais voltada a microsserviços. E notamos que em termos de bibliotecas e conhecimento nesse sentido a stack ainda estava atrás de outros players. Com o avanço do .NET Core as empresas começaram a utilizar mais containerização (docker) e outras práticas de DevOps, mas isso ainda era de certa forma recente para a stack que por muito tempo esteve focada apenas em ambientes Windows.

Ecossistema JVM

Você deve ter notado algo em comum nas outras 3 linguagens citadas: todas pertencem ao ecossistema JVM.

O ecossistema JVM fornece diversas bibliotecas e frameworks muito famosos no mercado, como o Spring, Hibernate, além de bibliotecas que fazem integração com diversas ferramentas que utilizamos, como o Camunda, Consul e Vault.

Isso chamou nossa atenção e nos tranquilizou: se errarmos e quisermos mudar entre essas linguagens, talvez possamos ter interoperabilidade entre o código já existente e o novo. Dependendo dos frameworks escolhidos poderíamos reaproveitar também o conhecimento deles (levando-os para outra stack). Um outro ponto diz respeito a uma espécie de “onipresença” da JVM, como alguns “.jars” que são providos pelo governo para fazermos validações de arquivos para a integração com o Banco Central — BACEN. Bom, voltemos às linguagens então.

Scala

Resolvemos dar uma olhada nessa linguagem que é muito consolidada no meio funcional.

Scala aparentemente resolveria nossos problemas muito bem, mas novamente um risco latente apareceu. Estávamos saindo de um paradigma orientado a objetos com a linguagem Ruby, ou seja, boa parte dos nossos desenvolvedores não tinham conhecimento sobre paradigma funcional.

Seria de fato um ramp up muito alto para a equipe ter que aprender: além de uma nova linguagem com todo seu ecossistema e frameworks, também um novo paradigma.

Java

É impressionante a quantidade de bibliotecas existentes rodando na JVM, sendo a maioria delas escritas em Java. Aparentemente Java poderia ser uma escolha segura para nós, mas com um breve aprofundamento na linguagem notamos que ela poderia também nos trazer novos problemas. Java, além de ser uma linguagem mais antiga do que as demais, manteve retrocompatibilidade por muito tempo. Isso retardou sua evolução. Java era uma linguagem ótima quando foi lançada, em 1995, mas hoje ao compará-la com linguagens modernas, sua sintaxe, verbosidade e falta de features a torna precária.

Com as evoluções mais frequentes iniciadas a partir do Java 9 a linguagem passou a ganhar alguns syntactic sugars, mas ainda não se comparava à legibilidade oferecida pelas demais. Isso fez com que não ficássemos tão entusiasmados com a linguagem. Checked e unchecked exceptions, fraca inferência de tipos, getters e setters, impossibilidade de fazer sobrecarga de operadores e criar extension functions são apenas alguns dos exemplos que nos desagradavam…

Kotlin

Mas poxa, e todo esse ecossistema de bibliotecas construídos em cima do Java e da JVM? Não vamos conseguir tirar proveito disso? Foi então, que no evento da QCon de 2018, vimos uma ótima palestra falando sobre Kotlin. Além disso, a palestra mostrava exemplos de Kotlin com DDD e Event Sourcing. Aquilo foi uma coincidência fabulosa. Uma linguagem com a sintaxe extremamente elegante e moderna, que rodava numa plataforma segura e de amplo alcance no mercado (JVM, apesar de que também compila para outras plataformas), e que atenderia muito bem nossas necessidades de DDD. Precisávamos testá-la.

Como dito anteriormente, temos um domínio bem complexo. Queríamos dedicar nosso tempo para resolver problemas de negócio, e não ficar codificando boilerplate para atender tarefas corriqueiras que frameworks poderiam fazer por nós. Jeff Atwood uma vez escreveu em seu blog que o melhor código é aquele que não escrevemos (“The best code is no code at all”), pois quanto menos código, menos testes escrevemos e também menos problemas de manutenção enfrentamos no dia-a-dia.

As features de Null Safety e Data Class, por exemplo, nos permitem não testar esse tipo de tarefa. O código compilou corretamente? Então o comportamento já foi validado! Tudo isso completamente abstraído pelas features do Kotlin. O Null Safety, em especial, é uma funcionalidade que na época não era oferecida por nenhuma das linguagens citadas (o C# implementou recentemente na sua versão 8). O Data Class existia apenas em Scala, e também foi implementado no C# 8.

Em relação ao Java exclusivamente, o site oficial do Kotlin, na sessão “comparison to Java”, possui uma listagem dedicada a comparar as funcionalidades de ambas as linguagens. Notamos que há também diversas características que não aparecem lá e que consideramos grandes vantagens de Kotlin numa comparação direta, muito pelo resultado derivado de algumas características já citadas anteriormente (como fraca inferência de tipos e excesso de verbosidade). Um exemplo é a interface de manipulação de listas detalhado nessa thread do Stack Overflow.

Mas então OK… Kotlin parecia ser uma ótima opção e nos deixou muito empolgados, mas qual seria o próximo passo? Deveríamos simplesmente migrar para Kotlin com JVM? Confira no próximo post.

Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa tripulação! Você pode conferir nossas vagas aqui.