La primera vez que mencioné kotlin en este blog fue hablando de TypeScript en 2012. Entonces estaba todavía en pañales, pero me pareció un lenguaje interesante. Tres años después, cuando escribía sobre featuritis en lenguajes de programación volví a mencionar a kotlin, de una forma un poco menos positiva porque me parecía que tendía a acumular demasiadas cosas en un mismo lenguaje (algo que sigo pensando).
En todo este tiempo no es que haya estado sumamente pendiente de la evolución del lenguaje, pero sí que lo he seguido desde la distancia. Desde hace unos tres años me planteo dejar de usar .NET, y la JVM es una plataforma que me atrae especialmente, por lo que trato de estar relativamente pendiente de su estado.
El anunció de Google este año del soporte oficial para Kotlin en Android ha hecho que aumente el hype, el lenguaje gane mucha popularidad y cabe esperar que eso redunde en una mayor base de usuarios.
Todo esto me lleva a plantearme si kotlin podría ser una opción práctica para futuros desarrollos. Como no soy ningún experto en el lenguaje y elegir un lenguaje de programación depende de muchos factores, voy a aprovechar este post para hacer un análisis en abierto de los puntos fuertes y débiles que veo en kotlin con la esperanza de que alguien pueda aportar su opinión al respecto.
El lenguaje
Como lenguaje, kotlin no me atrae demasiado. No es que lo considere un mal lenguaje (tampoco sé tanto sobre él), pero no es un lenguaje que aprendería para divertirme. Sin embargo, me parece un lenguaje práctico y en este caso es lo que estoy buscando.
Su sintaxis resulta familiar a cualquiera que esté acostumbrado a lenguajes basados en C (Java, C#, Javascript y compañía), lo que debería facilitar su aprendizaje (comparado, por ejemplo, con Clojure o Erlang). Además, es un lenguaje multiparadigma, con sus construcciones orientadas a objetos y funcionales. Tiene tipado estático y fuerte, lo que tiene sus ventajas a nivel de desarrollo y de tooling disponible.
Algunas de sus características me resultan especialmente atractivas, como la posibilidad de tener referencias no nullables, la facilidad de para declarar valores inmutables y la existencia de data classes.
Junto a esto, ofrece otro tipo de funcionalidades a las que estoy menos acostumbrado y que supongo se inspiran más en Scala, como companion objects u object declarations. La utilidad real de esto no soy capaz de juzgarla ahora mismo, por lo que asumiré que es algo maravilloso pero lo cierto es que no tengo muy claro para qué podría servirme.
La plataforma
Kotlin puede ser compilado a distintas plataformas: JVM, Android, Javascript o nativo. Actualmente, la parte de nativo o android no me interesa demasiado. Poder compilar a Javascript para ejecutar en un browser es un añadido interesante, pero no es algo que me quite el sueño porque es un problema que, de momento, tengo resuelto con TypeScript. Lo más interesante (y de hecho es por lo que llego a kotlin) es por la posibilidad de desplegar sobre la JVM.
La JVM garantiza un buen soporte multiplataforma y es una tecnología estable y madura, con infinidad de herramientas y documentación disponible para la parte de despliegue, administración y monitorización.
El ecosistema
Tanto en JVM como en Javascript (desconozco el resto de casos), kotlin puede interoperar con las librerías existentes en la plataforma host, lo que directamente abre la puerta a un buen número de librerías para resolver casi cualquier problema.
Aun así, esto no siempre es suficiente. Con TypeScript puedes usar cualquier librería de Javascript, pero si no tienes las definiciones de tipos, la experiencia se resiente mucho. Con Clojure puedes interoperar con Java de forma trivial, pero da lugar a un código tirando a feo y poco idiomático. Al final, si vas a depender de librerías diseñadas para otros lenguajes, quizá la mejor opción sea usar esos lenguajes directamente.
Dando un paseo rápido por github y haciendo un par de búsqueda en Google da la sensación de que todo el ecosistema de kotlin está todavía un poco verde. Seguramente crezca con el tiempo y siempre está la opción de crear tus propios wrappers ligeros sobre librerías de Java para hacerlas más amigables en kotlin, pero es un trabajo adicional que me lleva nuevamente a plantearme si no sería mejor usar Java directamente.
El propietario
Este es uno de los puntos que más me preocupa. Kotlin es open source, por lo que podría parecer que esto es irrelevante, pero lo cierto es que kotlin no es un proyecto de la comunidad, sino de JetBrains. Eso no tiene nada de malo, pero es algo que hay que tener en cuenta. Exactamente igual que pasa con C# o TypeScript (lenguajes que utilizo a diario).
Tengo serias dudas de que kotlin siguiera siendo viable sin el apoyo de JetBrains, y eso hace que elegirlo como lenguaje para desarrollar productos cuyo ciclo de vida es muchos años (+10) pueda resultar algo más arriesgado. No creo, sinceramente, que JetBrains vaya a desaparecer a corto plazo o que vaya a dejar de invertir en kotlin, pero nunca se sabe.
A esto se le une que JetBrains hace muy buenas herramientas de desarrollo. Probablemente, de las mejores junto con Microsoft. Y eso me pone nervioso. Despues de más de 15 años atado a Visual Studio para poder desarrollar con .NET, pensar que la oferta de herramientas de desarrollo para kotlin se va a limitar a lo que ofrezca JetBrains porque nadie se va a sentir capaz de competir con ellos, no me acaba de convencer.
A cambio, al igual que pasa con .NET, que el principal impulsor del lenguaje sea también el mismo que hace las herramientas de desarrollo, garantiza un excelente soporte en las mismas.
Resumen
Kotlin es un lenguaje que parece bastante accesible y, a la vez, flexible. Por ese lado, no parece una mala elección. A la hora de ampliar un equipo de desarrollo, cabe esperar que al ganar en popularidad sea más fácil encontrar gente que conozca kotlin, pero aunque no fuese así, no parece algo terriblemente complicado de aprender para gente que venga de otros lenguajes.
Poder desplegarse sobre la JVM es un punto muy a su favor, y la opción de compilarlo a Javascript podría acabar resultándome útil en algún momento. Utilizar estas plataformas host tiene la ventaja de que pone a tu disposición todas las librerías que ya existen, lo que ayuda a compensar la situación actual de librerías específicas para kotlin. Aun así, no sé si realmente es cómodo usar un API Java desde kotlin o acaba resultando demasiado alien y poco idiomático.
Tener detrás a una empresa como JetBrains hace que el futuro de kotlin quede ligado a ella, para bien y para mal. Asegura que al menos hay alguien invirtiendo en el lenguaje, y que Google lo considere lenguaje oficial para desarrollos sobre Android posiblemente ayude a darle continuidad.
Varias cosas:
– Por un lado, uno de los puntos fuertes de Kotlin es la intercompatibilidad casi total con Java (he encontrado algún problema de interoperabilidad con librerías como Lombok que tiran a lo bestia de preprocesado de anotaciones). Con esto quiero decir que utilizar casi cualquier librería/framework hecha con Java va a funcionar con Kotlin (por ejemplo Spring); pero es que no sólo es hecho, es que las librerías compiladas con Kotlin pueden ser utilizadas en proyectos Java sin ningun problema. Incluso Kotlin utiliza ciertas anotaciones para “configurar” su integración con Java haya donde dista mucho de éste (ejemplo: @JvmField o @JvmFile(“patata”))
– Por otro lado, esto es una predicción mia, pero creo que Kotlin ha venido para quedarse (y siendo muy “oraculos”, puede que para reemplazar por completo a Java) aunque sólo fuera por lo ya dicho anteriormente. ¿por qué lo creo?
+ Kotlin tiene un apoyo muy fuerte de la comunidad (google y spring)
+ La sintaxis de Java es noventeta y programar como se hace hoy en día dificulta brutalmente hacerlo de forma sencilla con Java
+ Los desarrolladores Java que trabajan con los actuales paradigmas de programación les da “sida” la sintaxis de Java y muchos aman la sintaxis de Kotlin
+ Lenguajes para la JVM hay infinítos (por ejemplo JYthon o JRuby) pero los que lo petan actualmente son Groovy y Scala. Un desarrollador Scala a día de hoy gana más de media que un desarrollador Java-Spring; ahi están. Para mí Kotlin es “como Scala para seres humanos” (todos mis respetos a Scala que está muy bien, aunque Kotlin le gana en interoperatividad). Groovy también tiene su nicho (he visto muchas ofertas pidiendo Groovy) y un nivel de interoperatibidad que roza al de Kotlin; pero claro, Groovy es dinámico. Kotlin tiene su nicho junto a Scala y Groovy sin lugar a dudas.
+ Java no es JavaScript donde mueren y nacen frameworks todos los días. Kotlin lleva ya un tiempo y tiene pinta de que seguirá siendo así
– Por último, a mi personalmente si que me parece un lenguaje divertido de aprender; es como el lenguaje que siempre hemos deseado todos. Especialmente útil si combinas IoC, DI, Single Resposability, inmutabilidad y funcional en tu día a día. Spring Boot+Kotlin es una combinación ideal para hacer aplicaciones en el backend.
Espero haber aportado mi granito de arena.
Un saludo,
Jorge
Muchas gracias, Jorge, me resulta muy útil tu visión.
¿Hay algún ORM (completo, no micro) para kotlin? ¿La opción realista sería tirar directamente de Hibernate?
Para mi kotlin es un lenguaje de medias tintas, y eso hace que tenga un futuro prometedor a corto/medio plazo pero no tanto a largo.
Un java modernizado a medias tiene el problema de que java, tarde o temprano (y mas con lo de «acelerar» los releases) le alcance o incluso le supere. Al no tener una faceta experimental (como scala) su recorrido esta limitado a las relativamente superficiales mejoras sobre su mayor competidor, que no es otro que java mismo.
O sea, puestos a ser practicos, pues uso java directamente, y si no me voy a ahorrar la @magia en kotlin pues la uso en java y lo dejo no taaaan diferente.
O sea, practico, aburrido (que sera una ventaja, no lo niego), demasiado parecido a java y con recorrido limitado y ligado a los intereses de google y jetbrains.
No lo había visto de esa manera, pero son muy buenos argumentos. Gracias, Sr. Neira.
La verdad es que todavía no he hecho una PoC con kotlin y hibernate. Imagino que haya que definir los pojos con “open” (no lo sé), pero a parte de eso supongo que funcionr perfectamente.
Un saludo,
Jorge
Hola jneira,
Creo que java arrastra ya demasiado legacy como para poder competir con kotlin (es mi opinión) aunque saquen las características de kotlin, la sintaxis en java va a ser infumable (creo)
Un saludo,
Jorge
Bueno, para mi la sintaxis tiene una importancia relativa. Hay un punto en la cantidad de «boilerplate» que la cosa empieza a ser de incomoda a inmanejable. No se si la diferencia entre las nuevas versiones de java y kotlin llegara a ese punto.
Las diferencias semanticas son las importantes y creo que la mas interesante que tiene kotlin y no java son las data classes, que parece que pueden ser añadidas al propio java
Por otra parte kotlin ya es hasta cierto punto «legacy»: al ser el lenguaje de referencia de android, ya no creo que cambie tan alegremente como al principio
Hola de nuevo jneira,
Ayer trate de contestar y se borró mi comentario (por error mío) así que trataré de recordar todo lo que quería decir.
Entiendo perfectamente tu punto de vista; pero sin embargo, creo que aunque Java alcance todas las nuevas features de Kotlin (en realidad no son sólo las data-classes) pasará lo mismo que pasó con los streams(), la inferencia de tipos o los genéricos pero todavía mucho más. Es decir, para hacer lo mismo que hacemos con Kotlin habrá que emplear, y sobretodo APRENDER, una berborrea anti-intuitiva llena de caracteres raros ¿acaso alguien externo (e incluso interno) a Java entiende un o un ?
El otro día tuve que explicarle a un compañero que List = List y que List = Una lista de la que no sabemos cual es su tipo y que, por tanto, no debía usar List sin porque eso se debía a un legacy de Java antes de que tuviera genéricos. ¿alguien sabe para lo que sirve implementar un método en una interfaz con el default? pues sirve porque Java inicialmente en las interfaces había que definir public abstract void foo(); para declarar un método, en la 6 ó 7 definieron que con poner void foo() era suficiente (incluso si tu pones int PI = 3 estás declarando una constante) y luego en Java 8 para poder extender la api de collection sin introducir los «extension methods» metieron los default methods y ahora resulta que si quieres que en una interfaz foo() tenga implementación tienes que poner default void foo(). El otro día otro compañero se definió una interfaz con todos los métodos default que realmente era una clase de funciones puras y tuve que explicarle esto también y por qué no debía hacerlo.
Para mi la sintaxis está directamente relacionada con la productividad. Es cierto que no es el factor más importante, pero es uno muy importante. Por ejemplo, la sintaxis de C# le da un millón de vueltas a la de Java (un sólo ejemplo, genéricos en tiempo de compilación que no son sintactic sugar) pero la comunidad de Java es mil veces más potente que la de C#, lo que hace que Java derrote a C#. Para mí la comunidad es lo que más afecta a la potencia o el poder de un lenguaje por la integración con terceros.
La sintaxis implica menor coste operacional, de mantenimiento y de aprendizaje. Así como «ayuda» al programador a trabajar adecuadamente con los paradigmas. Un ejemplo: Tu puedes usar el infumable Calendar de Java, Joda Time o JSR-310 (java.time) como apis de tiempo, sin embargo es mucho más fácil cometer errores graves con Calendar que con Joda, porque Joda tiene una semántica que ayuda a trabajar BIEN con el paradigma del tiempo.
Lo bueno, lo genial de Kotlin es que tiene lo bueno de C# (su sintaxis) y lo bueno de Java (su comunidad) y yo por tanto entiendo la inquietud de desarrolladores como Juan por este lenguaje.
Finalmente ya para concluir, las data-classes son una característica «efimera» de Kotlin. Lombok mediante la anotación @Data y su preprocesador hace prácticamente lo mismo que el data de Kotlin. Creo que Kotlin no lo peta por las data classes, sino por otras cosas como:
– Tipos de datos no nulables (para mí, lo más potente del lenguaje es esto)
– Inferencia de tipos
– Métodos de extensión
– Smart casts (eliminan multitud de ifs)
– Properties (en Java existen por «convención» y muchas liberías las usan siguiendo la convención de get, is, has/set, pero si quieres declarar un método que se llame «getInfoFromServer()» ¿eso es un getter o es un método?)
– Constructores primarios (MUY útiles en la inyección de dependencias o las clases de datos)
– Rangos
– Sobrecarga de operadores
– Api de colecciones con tipos mutables e inmutables (que al contrario que en Scala son interoperables con la api de Java Collections)
– Funciones inline
– String templates
– Closures (no es exactamente lo mismo un closure que una lamdba, a mi personalmente no me terminan de convencer por temas de scope)
– Corutinas
Encima se calzan las checked exceptions (lo cual ya estabamos haciendo en Java mediante la técnica del ñapeo). Algunas personas que les gusta trabajar con el anti-patrón «flujo por excepciones» pensarán que es un error; pero es que no debemos hacer flujo por excepciones, las excepciones debería controlarlas la parte más alta de nuestra aplicación y a poder ser todas o casi todas de la misma manera.
Luego al margen de todo esto creo que JetBrains tiene una visión de producto espectacular, saben lo que el programador quiere y es en lo que se centran; pondré un ejemplo, tu estás en stack overflow copias un código escrito en Java y lo pegas en IntelliJ en un proyecto con un fichero Kotlin, el ide te pregunta: «oye esto es Java… quieres convertirlo a Kotlin?» la conversión no es perfecta pero impresiona lo bien que funciona en el 80-90 % de los casos de complejidad media.
Un saludo,
Jorge
Hola de nuevo jneira,
Ayer trate de contestar y se borró mi comentario (por error mío) así que trataré de recordar todo lo que quería decir.
Entiendo perfectamente tu punto de vista; pero sin embargo, creo que aunque Java alcance todas las nuevas features de Kotlin (en realidad no son sólo las data-classes) pasará lo mismo que pasó con los streams(), la inferencia de tipos o los genéricos pero todavía mucho más. Es decir, para hacer lo mismo que hacemos con Kotlin habrá que emplear, y sobretodo APRENDER, una berborrea anti-intuitiva llena de caracteres raros ¿acaso alguien externo (e incluso interno) a Java entiende un
o un?El otro día tuve que explicarle a un compañero que
List = Listy queList = Una lista de la que no sabemos cual es su tipoy que, por tanto, no debía usarList sinporque eso se debía a un legacy de Java antes de que tuviera genéricos. ¿alguien sabe para lo que sirve implementar un método en una interfaz con el default? pues sirve porque Java inicialmente en las interfaces había que definir public abstract void foo(); para declarar un método, en la 6 ó 7 definieron que con poner void foo() era suficiente (incluso si tu pones int PI = 3 estás declarando una constante) y luego en Java 8 para poder extender la api de collection sin introducir los «extension methods» metieron los default methods y ahora resulta que si quieres que en una interfaz foo() tenga implementación tienes que poner default void foo(). El otro día otro compañero se definió una interfaz con todos los métodos default que realmente era una clase de funciones puras y tuve que explicarle esto también y por qué no debía hacerlo.Para mi la sintaxis está directamente relacionada con la productividad. Es cierto que no es el factor más importante, pero es uno muy importante. Por ejemplo, la sintaxis de C# le da un millón de vueltas a la de Java (un sólo ejemplo, genéricos en tiempo de compilación que no son sintactic sugar) pero la comunidad de Java es mil veces más potente que la de C#, lo que hace que Java derrote a C#. Para mí la comunidad es lo que más afecta a la potencia o el poder de un lenguaje por la integración con terceros.
La sintaxis implica menor coste operacional, de mantenimiento y de aprendizaje. Así como «ayuda» al programador a trabajar adecuadamente con los paradigmas. Un ejemplo: Tu puedes usar el infumable Calendar de Java, Joda Time o JSR-310 (java.time) como apis de tiempo, sin embargo es mucho más fácil cometer errores graves con Calendar que con Joda, porque Joda tiene una semántica que ayuda a trabajar BIEN con el paradigma del tiempo.
Lo bueno, lo genial de Kotlin es que tiene lo bueno de C# (su sintaxis) y lo bueno de Java (su comunidad) y yo por tanto entiendo la inquietud de desarrolladores como Juan por este lenguaje.
Finalmente ya para concluir, las data-classes son una característica «efimera» de Kotlin. Lombok mediante la anotación @Data y su preprocesador hace prácticamente lo mismo que el data de Kotlin. Creo que Kotlin no lo peta por las data classes, sino por otras cosas como:
– Tipos de datos no nulables (para mí, lo más potente del lenguaje es esto)
– Inferencia de tipos
– Métodos de extensión
– Smart casts (eliminan multitud de ifs)
– Properties (en Java existen por «convención» y muchas liberías las usan siguiendo la convención de get, is, has/set, pero si quieres declarar un método que se llame «getInfoFromServer()» ¿eso es un getter o es un método?)
– Constructores primarios (MUY útiles en la inyección de dependencias o las clases de datos)
– Rangos
– Sobrecarga de operadores
– Api de colecciones con tipos mutables e inmutables (que al contrario que en Scala son interoperables con la api de Java Collections)
– Funciones inline
– String templates
– Closures (no es exactamente lo mismo un closure que una lamdba, a mi personalmente no me terminan de convencer por temas de scope)
– Corutinas
Encima se calzan las checked exceptions (lo cual ya estabamos haciendo en Java mediante la técnica del ñapeo). Algunas personas que les gusta trabajar con el anti-patrón «flujo por excepciones» pensarán que es un error; pero es que no debemos hacer flujo por excepciones, las excepciones debería controlarlas la parte más alta de nuestra aplicación y a poder ser todas o casi todas de la misma manera.
Luego al margen de todo esto creo que JetBrains tiene una visión de producto espectacular, saben lo que el programador quiere y es en lo que se centran; pondré un ejemplo, tu estás en stack overflow copias un código escrito en Java y lo pegas en IntelliJ en un proyecto con un fichero Kotlin, el ide te pregunta: «oye esto es Java… quieres convertirlo a Kotlin?» la conversión no es perfecta pero impresiona lo bien que funciona en el 80-90 % de los casos de complejidad media.
Un saludo,
Jorge
Nota: Pido disculpas por repetir el mensaje, pero al no conocer el funcionamiento del blog las partes que había escrito con mayor que y menor que no se han pasado bien.
Al final no he conseguido que el ejemplo que quería poner con genéricos salga bien. Así que pido disculpas.
Un saludo
Por favor, pruebe Scala para que nos deleite con sus siempre sensatos
y educativos comentarios.
Escribe usted con tal claridad y mesura, que es de los pocos blogs en los que los trolls no tienen lugar y es casi imposible iniciar un flame.
Dado que piensa cambiar, hagalo con algo que , adicional a los aspectos pragmáticos, le implique ahondar en nuevos territorios y abstracciones como los typeClasses (genericos de mayor nivel ??) y todo la parafernalia funcional .
He leido con frecuencia, que Scala es demasiado grande, tiene de todo !!! pero por lo menos evita tener que esperar a la próxima versión para que agreguen tal o cual característica y celebrarla como una gran innovación, precisamente porque de seguro ya lo tiene. Creo que pocas personas de habla hispana de los blogs que sigo, tienen la lucidez para evaluar que tan coherente fue el intento de Odersky por compaginar el paradigma funcional junto al orientado a Objetos.
También creo que Scala es la dirección a donde apunta c#.
Intente con Scala y comentemos sus experiencias, para el aprendizaje de toda la comunidad que lo sigue.
Hola soy Ivan, me gusta mucho ❤️ kotlin por su sencillez, no se mucho sobre java, pero si lo llegue a tocar cuando editaba algo llamado «emuladores para juegos», me gustó mucho pero veía que había que escribir muuuchas líneas de código para expresar una funcionalidad pequeña como el caso de una clase sencilla. Ejemplo en Kotlin : class Perro(Nombre : String, Pseudo: String, Edad: Int, tieneDueño: Boolean, nombres pero:String) (pudiendo heredar de una superClase muy fácilmente) está misma línea en java es un poco más extensa (12 líneas). Tengo 17 años y tal vez apenas estoy empezando al recorrido pero igual les dejo mi humilde opinión. :3
A mi me encanta Kotlin, depende mucho de los gustos de cada quien.