¿Es Kotlin la próxima gran cosa en el ecosistema JVM?

Obviamente, es realmente difícil de predecir, pero creo que tiene mucho que ofrecer y un impulso significativo.

Hace un par de años, muchos lo descartaron como una pérdida de tiempo para que JetBrains invierta. Sin embargo, otro lenguaje JVM, ¿no tenemos suficiente? Es solo una Scala menos capaz. Un Groovy de tipo estático.

Sin embargo, donde Kotlin se ha ganado a la gente, creo que es con 3 cosas:

  1. Facilidad de comenzar. Literalmente, puede mezclar el código de Kotlin con el código de Java en el mismo proyecto. La curva de aprendizaje para el idioma es bastante superficial (tal vez menos que Groovy). La biblioteca estándar es pequeña (compárese con Scala con su biblioteca de colecciones completamente diferentes y una gran cantidad de problemas con implicidades que convierten cosas de un lado a otro para interoperabilidad, por ejemplo). Interopera mejor con Java que con cualquier otro lenguaje JVM. No requiere herramientas especiales o sistemas de módulos (el sistema de tipos de Ceylon es más poderoso que el de Kotlin, pero no puede simplemente arrojar un código de Ceilán en un proyecto existente).
  2. Soluciones simples a las frustraciones cotidianas en Java. ¿Seguridad nula? – comprobar. ¿Incompatibilidad de tipos de opciones con bibliotecas heredadas? – comprobar. ¿Se requiere repetitivo para definir los tipos de valor? – comprobar. ¿Tipo de fundición excesivo? – comprobar. ¿API funcional que va más allá del mínimo? – comprobar. Escriba DSL seguras? – comprobar. ¿Capacidad para ampliar las bibliotecas principales (sin fugas de extensiones y manteniendo la compilación estática)? – comprobar. Corutinas? – comprobar. Cadena con plantilla? – comprobar. La lista continua. Otros idiomas tienen algunos, incluso muchos de esos. No conozco ninguno en la JVM que los tenga todos.
  3. Las herramientas son geniales. Por supuesto que es. El lenguaje está hecho por las personas que construyen el IDE. Groovy tardó años en obtener un soporte IDE medio decente y todavía no es tan bueno como eso para Java (es más difícil soportar un lenguaje de tipo dinámico ya que el IDE tiene que confiar en la heurística y el conocimiento de las bibliotecas hasta cierto punto). El soporte de Scala en IntelliJ es decente, pero es propenso a agotar los recursos del sistema (puede decirle a las personas que codifican en Scala porque puede escuchar a los fanáticos de la CPU desde el otro lado de la habitación).

Con el primer Gradle y ahora Google saltando a bordo, el idioma tiene credibilidad. Aunque cualquier programador sensato no solo dice “oh, Google lo está usando así que debería usarlo”, ese tipo de crédito es importante para afianzarse en organizaciones más conservadoras e inertes (la mayoría de ellas).

JetBrains y Google van a establecer una fundación sin fines de lucro para administrar el lenguaje, por lo que ya no será el “lenguaje JVM patentado de JetBrains”.

Kotlin definitivamente tiene una oportunidad de ser grande. No va a desplazar a Java en el corto plazo, nada lo es. Sin embargo, puedo ver que se está volviendo muy popular.

Las respuestas ya proporcionan argumentos razonables. En Pivotal, la compañía detrás de un popular ecosistema JVM (Spring Framework), estamos invirtiendo un poco de esfuerzo y tiempo en hacer que Kotlin brinde un apoyo ciudadano de primera clase. Spring no es Android, pero influye en una audiencia considerable de JVM (las estadísticas de Spring Boot superaron los 12 millones de dl / mes la última vez que lo verifiqué).

Kotlin aún no es perfecto, y la OMI está a años de distancia antes de obtener una credencial cercana al lenguaje de fábrica JVM, hasta ahora Java 8, pronto 9. Lambda / MethodHandle / DefaultMethods han comenzado a canibalizar en territorio Scala y Groovy. Las versiones futuras de Java podrían incluir una especie de inferencia de escritura que también podría canibalizar más estas extensiones JVM.

Luego, con la programación reactiva convencional, veo aún menos espacio dado el vocabulario proporcionado por extensiones como Reactor 3 o RxJava 2. Ser un poco más detallado a veces es una cualidad subestimada.

Quizás el futuro de Kotlin no sea necesariamente competir con Java 8+, sino proporcionar un puente natural a través de WebAssembly hacia otras plataformas que están fuera del alcance de la JVM.

Dicho todo esto, es tan agradable y poco arriesgado comenzar con Kotlin que podrías hacer la pregunta “¿por qué no?”.

Es difícil de predecir, pero los datos no parecen apoyar una revolución de Kotlin, a pesar del movimiento reciente de Google.

Primero echemos un vistazo a los Contenders: Scala, Groovy, Closure y Kotlin

Groovy es un lenguaje de script, Closure es Lisp en la JVM, Scala trata de ser todo para bien o para mal, y Kotlin es realmente una respuesta a su intento de ser un mejor Java.

Veamos las tendencias de Google:

Tendencias de Google

Scala es claro en la delantera, seguido por Groovy, luego Closure y Kotlin muertos el último año durante el año pasado con un gran aumento tras el anuncio de Google.

No siempre confío en Google para desambiguar el uso de los términos, así que también trato de agregar algo a cada término para asegurarme de que estamos discutiendo el lenguaje de la computadora, agrego “tutorial” a cada término, menos volumen pero definitivamente relevante , con un posible sesgo hacia los recién llegados (lo cual es bueno para nosotros).

Más o menos la misma imagen (supongo que la desambiguación de Google no es tan mala)

Pero centrémonos en lo que sucedió con el anuncio: ¿Esto va a cambiar todo, a pesar de que el idioma ha existido por un tiempo? ¿Google cambiará la tendencia?

Vemos que el bombo se disipa rápidamente.

Kotlin no irá a ninguna parte, es un buen lenguaje, pero no veo venir una revolución. Scala no va a ninguna parte, pero no causó una revolución.

Creo que Kotlin es superior a Java, es más simple que Scala para bien o para mal y estaría feliz de ver a las personas alejarse de Java en masa. Simplemente no veo que suceda pronto.