Diferença entre kotlin e java

Nota introdutória: Sou desenvolvedor profissional há quase 30 anos e desenvolvedor Java há 25 desses anos. Coloquei meu primeiro aplicativo Java em produção no mesmo dia em que o Java 1.0 foi lançado; portanto, não pense que estou cagando em todo o Kotlin só porque é novo. Eu já vi muitos modismos da JVM ir e vir - Groovy, Scala, Clojure, etc.

Mas Kotlin é de fato a Nova Gostidade, e por isso compartilharei alguns pensamentos:

O que é bom

O Kotlin é uma linguagem JVM bem projetada com várias melhorias significativas em relação ao Java e à maioria das outras linguagens JVM:

  • Segurança nula inerente
  • Operadores de infix (que permitem fácil construção de DSLs)
  • Programação Coroutine
  • Métodos de extensão para permitir um melhor encapsulamento de objetos no código que você não possui.
  • Funções como um objeto de primeira classe
  • Inúmeras extensões funcionais de objetos úteis (como Any.apply)
  • Construção POJO simplificada por meio de classes e propriedades de dados como um objeto de primeira classe.
  • Linter padrão para um estilo de codificação uniforme.

Contribuí para a manutenção de algumas bases de código Kotlin e achei a experiência agradável em geral. Pretendo continuar aumentando meu conhecimento e nível de conforto com a Kotlin.

O que não é tão bom

Ainda não considero o Kotlin um substituto de primeira classe para Java em todos os contextos:

  • A linguagem ainda é imatura, e idiomas não foram bem estabelecidos. Observar uma base de código Kotlin às vezes me lembra os dias do Perl - você pode encontrar 35 abordagens diferentes para resolver o mesmo problema, e isso constantemente viola o princípio da "menor surpresa".
  • Embora a maior expressividade do Kotlin reduz a complexidade imposta pelo clichê Java, ele pode criar um conjunto diferente de complexidades. Os métodos de extensão podem quebrar o encapsulamento e levar a todos os problemas que os globais nos causaram nos velhos tempos.
  • O JetBrains se move rapidamente com o Kotlin e tende a produzir muitos recursos experimentais tentadores que podem destruir rapidamente os sistemas de produção se não forem cuidadosamente considerados.
  • Às vezes, a segurança nula de Kotlin pode se comportar mal com objetos importados das bibliotecas Java - por exemplo, você geralmente recebe orientações confusas do compilador quando precisa afirmar a segurança nula via !! operador.
  • Para programas financeiros e de nível intermediário, o Ktor não é tão maduro quanto o Spring e o Dropwizard, e a adaptação dos padrões do Spring / Dropwizard ao Kotlin consome bastante esforço.
  • Finalmente conseguimos o controle sobre o ecossistema Java da Oracle, por que diabos você o substituiria por um ecossistema controlado pelo JetBrains?

Java continua a evoluir e permanece bom o suficiente para a maioria dos programas de negócios:

  • As extensões funcionais do JDK 8 atingiram a maturidade total e um conjunto de idiomas bastante padrão surgiu para melhorar a expressividade e o fluxo dos programas Java.
  • No JDK11, a segurança nula pode ser garantida com uma disciplina cuidadosa em torno das correntes opcionais.
  • O JDK11 possui variáveis ​​locais anônimas para melhorar bastante a clareza e a expressividade do Java.
  • Lombok é amplamente adotado e extremamente maduro e reduz bastante o clichê dos POJOs.
  • As estruturas modernas de concorrência baseadas no padrão Actor, como o ReactiveX e o Akka, são independentes do idioma e oferecem muito mais flexibilidade e oportunidade de reflexão sobre o design do que se prender à mentalidade de suspender / assíncrono {} de Kotlin.
  • O aprendizado de novos padrões de desenvolvimento em Java pode ser realizado muito mais rapidamente do que o aprendizado de uma nova linguagem, e pode ser adquirido iterativamente, visando a melhoria contínua como desenvolvedor.

Minha opinião profissional:

  1. Nos domínios em que a adaptação ao Kotlin tem sido extremamente agressiva (por exemplo, desenvolvimento de aplicativos Android), recomendo fortemente a adoção do Kotlin. Outro bom argumento para o Kotlin é o DSL Gradle Kotlin - o Groovy é uma linguagem moribunda, então é melhor você tentar.
  2. Em outros domínios, especialmente na programação de negócios corporativos, recomendo uma abordagem de esperar para ver. O pool de mão-de-obra para programadores Java experientes é pelo menos duas ordens de magnitude maior do que para o Kotlin. Forçar engenheiros talentosos e experientes a passar vários meses de seus esforços produtivos aprendendo um novo idioma geralmente não é uma boa idéia ao escolher um idioma para software de missão crítica.
  3. Todos os desenvolvedores de Java devem procurar oportunidades de aprender e abraçar o Kotlin, porque, embora eu ache que o Kotlin ainda não tenha deixado a “zona da moda” ainda, ele conseguiu evitar repetir os erros de Scala e Clojure, e há uma maior probabilidade de que o Kotlin tenha habilidades. pagará no futuro. Isso é especialmente verdadeiro se as tendências da arquitetura "sem servidor" prevalecerem e os desenvolvedores da camada intermediária se tornarem cada vez mais forçados ao domínio da pilha completa. Kotlin é uma boa aposta para o futuro.