Recientemente, se publicó una publicación muy específica sobre Kotlin en nuestro blog: no muy seria, más bien superficial e inesperadamente llena de vida. Pero somos conscientes de que criticar una tecnología al pasar varios días estudiándola es de mala educación. Y esta vez decidimos hablar sobre Kotlin con una persona que escribe sobre él en la versión 1.0.
Hoy, el nombre Kotlin ya es difícil de sorprender a nadie, especialmente en el desarrollo de Android. Tal vez fue a principios de 2016: la demanda fue un orden de magnitud menor, el soporte oficial para Google todavía estaba fuera de discusión, y escribir en Kotlin era un espíritu audaz.
Anton Keks se convirtió en uno de esos temerarios, y más tarde también le prestó mucha atención a Kotlin (por ejemplo, actuó dos veces en KotlinConf). Por lo tanto, decidimos preguntarle acerca de cómo la vida del desarrollador de Kotlin ha cambiado con el tiempo.
Y para no levantarse dos veces, cubrieron otro tema. Anton es cofundador de la compañía estonia Codeborne, que practica una programación extrema, por lo tanto, al mismo tiempo, aprendieron qué hay en Estonia con TI y cómo crear su propia compañía allí.
- ¿Cómo empezaste a escribir en Kotlin y cómo lo usas ahora?- Comenzó a usarse a principios de 2016, a partir de la versión 1.0. Mi primer proyecto en Kotlin fue el más seguro: un complemento para IntelliJ IDEA, que hice para un cliente japonés. Después de eso, comencé y transferí mis proyectos personales de Java a Kotlin, e intenté usarlo para el backend.
En el último año, hemos estado usando el lenguaje en el backend en el entorno bancario, estamos trasladando gradualmente el gran proyecto Java a Kotlin. Y escribimos microservicios en él, y hay Kotlin limpio. Cuando tiene un proyecto solo en Kotlin, todo se vuelve aún más agradable: no necesita pensar en la interoperabilidad con Java.
- Desde que vio el idioma desde la versión 1.0 hasta la actual 1.3, ¿cómo cambió desde el punto de vista del desarrollador que escribió en él?- Al principio, pensé, desde la versión de lanzamiento, entonces todo ya es increíble y funcionará sin problemas. Resultó que no fue así, y la primera brecha, entre 1.0 y 1.1, es en gran medida una corrección de las existencias, una mejora en el rendimiento, etc. Pero las versiones 1.2 y 1.3 son sobre nuevas características.
Por ejemplo, las corutinas que se han vuelto estables en 1.3 pueden hacer una gran diferencia. Jugué con ellos y estoy muy contento. Es cierto que en la producción aún no los hemos probado: todo aún descansa en las dificultades asociadas con los controladores JDBC. Pero en el desarrollo para Android, es más fácil construir un modelo asincrónico, por lo que los desarrolladores de Android usaron rutinas de hasta 1.3.
Y lo que sigue siendo muy interesante: en la versión 1.2, apareció soporte experimental para proyectos multiplataforma, fue posible compilar en JavaScript con Kotlin / JS, y en código nativo con Kotlin / Native. Pero por ahora, compilar en JavaScript me da miedo, y con Native, el principal problema es que Kotlin tiene una biblioteca estándar muy pequeña. En el caso de la JVM, Kotlin depende mucho de la biblioteca estándar de Java. Y en Kotlin / Native, en teoría, puede usar cualquier biblioteca nativa, pero luego pierde "multiplataforma completa", todo se vuelve separado. Sin embargo, JetBrains está trabajando actualmente en ello, y la plataforma cruzada puede tener un gran futuro. Las aplicaciones multiplataforma para iOS / Android son lo que a muchos les gustaría.
- Tanto Xamarin como React Native ya han intentado dárnoslos ..."Todos tienen un problema que Kotlin no enfrenta". En el caso de React Native, Xamarin y similares, el marco debe mantenerse al día con las versiones del sistema operativo. Algo se rompe constantemente, y todos estos marcos no se mantienen. Está en un estado incomprensible cuando ya se ha lanzado una nueva versión del sistema operativo, y su marco aún no funciona, y aún necesita hacer algo. Este es el momento más desagradable. Y con Kotlin en este sentido, todo es diferente: utilizan directamente todas las API y bibliotecas estándar del idioma.
- A menudo, una característica en Kotlin aparece como una "experimental", y logra cambiar antes de una versión estable. ¿Te gusta este enfoque? Si usa características experimentales, ¿cuánto cambian y cuánto tiene que rehacer?- Sí, me gusta Debido a que realmente hubo muchos errores en las versiones beta y los candidatos de lanzamiento 1.3 (incluso para
mi informe con rompecabezas, encontré un par de rompecabezas sobre este tema), y en la versión final los solucionaron, y esto es muy bueno.
En las rutinas, algunas cosas se han vuelto un poco más complicadas, pero ha quedado más claro lo que está sucediendo: por ejemplo, se hizo necesario transmitir más explícitamente el contexto a las rutinas. Y al final, el código con corutinas escritas bajo Kotlin 1.2, ahora simplemente no se compila. Pero al mismo tiempo, estos cambios no son tan grandes como para que sea difícil migrar.
- Si no estamos hablando del lenguaje en sí, sino, por ejemplo, del IDE, ¿hacia dónde se dirige el desarrollo? ¿Cómo eran las cosas antes y ahora qué?- Dado que JetBrains produce tanto el lenguaje, el compilador como las herramientas, hubo una situación sin precedentes en términos de soporte en el IDE. Muy a menudo, cuando nace un idioma, los primeros usuarios se escriben inicialmente en él en un editor de texto sin resaltar, y cosas por el estilo. Y con Kotlin esto ni siquiera era hasta la versión 1.0, el soporte en el IDE fue inmediato.
Sin embargo, no era ideal, y con el tiempo está mejorando constantemente, con cada versión menor, se agregan inspecciones. Y lo que es ahora es mucho mejor de lo que era. Por ejemplo, uno de esos errores que estaba esperando para solucionarlo: hay cadenas de plantillas en Kotlin, y quería intentar usarlas en lugar de otro lenguaje de plantillas en mis proyectos, pero debido a un error en el IDE, el resaltado se rompió tan pronto como comenzó la variable dentro de la cadena de plantilla en Kotlin Y ahora finalmente está arreglado, así que comencé a usarlo. Por el momento, ya no tengo cosas específicas que no me convengan.
- ¿Qué pasa con el desarrollo del ecosistema en su conjunto: la comunidad, las respuestas a Stack Overflow, los marcos?- Hasta donde puedo ver, la comunidad es muy activa, hay mucha actividad en Slack. Stack Overflow ya se ha escrito lo suficiente. Quizás el único problema es que cuando google, a veces hay algunas publicaciones que se escribieron antes de la versión 1.0, cuando algunas características eran completamente diferentes. Tienes que seguir la relevancia.
Hay marcos que se hacen inmediatamente específicamente para Kotlin. Por ejemplo, un excelente marco para pruebas unitarias MockK, está diseñado para Kotlin, hay API mucho más hermosas. Además, muchos frameworks Java ahora también se dedican específicamente a admitir Kotlin, no es estrictamente necesario con su interoperabilidad, sino que agregan algunos chips o hacen que el uso sea aún más conveniente.
- ¿La explosión de popularidad en el mundo de Android no condujo a un sesgo en la comunidad, cuando todos se preocupan solo por Android, y otras plataformas se han desvanecido en el fondo?"De alguna manera no me siento sesgada". Por supuesto, la decisión de Google de hacer de Kotlin el idioma oficial de Android afectó dramáticamente el aumento del interés en el idioma, pero me parece que no solo disparó a Android, sino también al interés en el idioma en general. Hubo muchos desarrolladores de Android en KotlinConf, pero también hay muchos de los que escriben aplicaciones de servidor, escritorio, incluso JS: conocí a personas que realmente usan la escritura de código tanto para el lado del cliente como para el lado del servidor. Y no existe la sensación de que sea "un lenguaje para Android". Aunque Android se ha convertido en un motor de interés, sigue siendo un lenguaje de uso general.
- Con las nuevas tecnologías, existe el temor eterno de "interesante, pero aún no se puede arrastrar a la producción", y en Android no existe ese problema, pero fuera de Android todavía hay una pregunta. Si tales preocupaciones son relevantes para Codeborne, entonces, en el tiempo que usa Kotlin, ¿qué ha cambiado?- Elegimos principalmente la tecnología nosotros mismos, pero a menudo sucede que el cliente también quiere participar en la toma de decisiones. Y en este momento, cuando llevamos a Kotlin a diferentes proyectos, no hay objeciones. Lo que ha cambiado: antes, los clientes no habían escuchado nada sobre Kotlin, pero ahora ya está en la audiencia. Y ahora, si decimos "estamos empezando a cambiar a Kotlin", ya no hay temor, por ejemplo, de que desaparecerá. Está la Fundación Kotlin, JetBrains y otras compañías en buenas condiciones financieras. Y el apoyo de la comunidad es excelente. En general, hay absoluta confianza en que Kotlin no irá a ningún lado.
- Muchos vienen a Kotlin ahora, habiendo omitido las etapas descritas del desarrollo del lenguaje. Esto solo puede ser envidiado, porque ya han adquirido una tecnología más madura, o sin la experiencia de los primeros en adoptar, ¿pierden algo importante?- Depende de la persona, que es más interesante para él. Al conectarse antes, uno podría participar personalmente en el desarrollo, influir en la formación. Especialmente antes de la versión 1.0, hubo un momento en que podía hablar con el equipo de JetBrains, influir en sus decisiones, ayudarlos. Y ahora el equipo sigue recurriendo a la comunidad y teniendo en cuenta su opinión, pero al mismo tiempo ya se han tomado muchas decisiones básicas y no cambiarán. Por lo tanto, todo depende del interés personal en tales.
En mi opinión, comenzar a usar la tecnología para el desarrollo cuando ya no es en bruto ayuda mucho: pasas tiempo en tus tareas y no en fallas. Y su herramienta simplemente funciona para usted. Creo que ha llegado el momento en que los que no prueban Kotlin, ahora llegan muy tarde y pierden mucho.
- Ahora que todo está bien en general, ¿qué le falta personalmente en el caso de Kotlin?"Quizás dos cosas pequeñas". Bastante menor es un operador ternario. Está claro que, dado que si es una expresión, simplemente puede usarla, pero desea escribir de manera más familiar.
Un poco más grande: paquete de acceso local. Me parece que interno en Kotlin es más un error. Intentaron mejorar lo que hay en Java, pero, en mi opinión, lo hicieron en vano. En Java, esto funcionó más o menos bien, e interno solo es útil si está escribiendo una biblioteca, no una aplicación normal. Y extraño el control de acceso de grano fino que tiene Java.
Bueno, quiero desarrollar un desarrollo multiplataforma, del que ya hablé. Allí debe trabajar en una biblioteca estándar. Pero también existe el marco Ktor, y ahora es un banco de pruebas para escribir todo en Kotlin, y algunas bibliotecas están surgiendo de este proyecto.
- Pasemos a la segunda parte de las preguntas: Estonia, Codeborne, emprendimiento. Para empezar, una pregunta inaccesible: ¿cómo es vivir en Tallin en general?- Tal vez no soy la persona adecuada para esta pregunta, porque soy fanático de Tallin, me parece que este es el mejor lugar en la Tierra. Por un lado, tenemos la Unión Europea, la moneda europea, el orden europeo y la pureza europea. Por otro lado, puedes usar el idioma ruso bastante ampliamente (un tercio de la población lo habla con seguridad), y estamos geográficamente cerca. Muchos especialistas en TI de Rusia, Ucrania y Bielorrusia nos visitan ahora. Creo que es precisamente por estas razones.
La ciudad no es tan grande como Moscú o San Petersburgo, por lo que no pasa mucho tiempo en transporte, y a menudo es conveniente llegar a pie. Al mismo tiempo, si quieres variedad, es fácil viajar al extranjero. Y en términos de precios, Tallin es más barata que Inglaterra y otros países europeos, por lo que el nivel de vida que puede pagar por el mismo salario en Tallin es mucho más alto.
De las desventajas, solo el clima. En verano es muy bueno, y en invierno es hermoso con nieve, pero noviembre es un mes muy deprimente.
- Bueno, no te acostumbras a los últimos Petersburgers / Moscovitas. ¿Y qué hay del país con TI?- Tenemos un nivel muy alto de desarrollo tecnológico. Todo lo relacionado con el "estado electrónico" se está desarrollando activamente, hasta el programa de residencia electrónica, cuando puede convertirse en residente de un país en línea, sin estar nunca en él. Muchos servicios en línea, que son nuevos en otros países, los damos por hecho. Aparecen nuevas empresas, por ejemplo, Skype era originalmente estonio. Los trabajos también son abundantes. Por lo tanto, diría que hay muchas cosas interesantes para los especialistas de TI.
- Suena repentinamente: intuitivamente, parece que tales centros de TI estarán en lugares como el Valle, y no en un país con una población menor que la de Novosibirsk.- Bueno, en el Valle es solo una persona de TI que podría ser peor, hay precios inmobiliarios poco realistas y, en general, el costo de vida.
Y, tal vez, se escribe poco sobre Estonia en fuentes rusas, pero si se mira la prensa internacional, entonces hay muchos textos en el espíritu del "estado electrónico, el primero en el mundo" (aquí hay un
gran ejemplo ). Cuando voy a conferencias de TI en todo el mundo, me dicen: “¿Estonia? ¡Oh, tienes tal TI allí!
Y además, cerca de Tallin está Helsinki, entre ellos una hora y media por agua o 15 minutos en helicóptero. Y hay negociaciones para fusionar Tallin-Helsinki en un centro europeo de TI. Es posible un túnel entre dos ciudades, entonces será el túnel más largo del mundo.
- Cuando se encuentra en un país con una pequeña población de TI grande, ¿es probable que funcione principalmente para clientes extranjeros?- Sí, cualquier empresa que esté surgiendo aquí quiere salir al mercado internacional lo antes posible. El interior es pequeño en número de personas. Pero gracias al hecho de que estamos en la Unión Europea, tenemos el mercado de la Unión Europea de inmediato. Y además, un pequeño mercado interno le permite a TI probar algunas cosas antes del lanzamiento mundial.
- Muchos rusos, en la mente de los estados bálticos, se están fusionando, así que aclaremos: ¿cuánto se aplica lo que se ha dicho sobre Estonia a Letonia y Lituania?- No muy aplicable, en realidad. Hay algunas intersecciones, pero la mentalidad es diferente, para los letones y lituanos está más cerca de Europa del Este. La historia de los países también es completamente diferente. Por lo tanto, si vienes a dar un paseo por Tallin, Riga y Vilna, sentirás que son diferentes, y si vives más, habrá aún más diferencias.
Érase una vez que trabajé con los letones y los lituanos en el trabajo; luego, los estonios resultaron ser los más progresistas en TI, luego adoptaron a los letones y a los lituanos incluso más tarde.
- Usted es uno de los cofundadores de la compañía estonia Codeborne. Para empezar, cuéntenos.- Somos pequeños, somos 32. Todos los desarrolladores, los llamamos no "desarrolladores", sino "artesanos del software". Esta es una diferencia muy importante, porque no tenemos analistas, evaluadores o gerentes de producto. Tenemos personas universales de fullstack que, además del desarrollo de fullstack, también se ocupan directamente del cliente sin intermediarios que puedan establecer tareas por sí mismos. Gracias a esto, la eficiencia es muchas veces mayor que la de muchas otras empresas de TI. Podemos construir cosas con dos o cuatro personas para las cuales se requerirán miles de personas para el Sberbank condicional. Por cierto, no estoy bromeando, hablamos con Sberbank sobre este tema, estaban interesados en interactuar. Pero me parece que a gran escala, tal eficiencia como las pequeñas es imposible. Por eso no queremos crecer demasiado. Cultura de la empresa: actúe rápidamente, haga que pequeñas cantidades de personas sean súper eficientes, resuelva grandes problemas para que el cliente no espere seis meses. Para esto usamos, por ejemplo, programación extrema y programación de pares.
- ¿Es todo este extremo extremo una característica particular de Codeborne, o es típico de Estonia en general? En otro país, ¿podrías?- Digamos que el aggel en Estonia es típico, los equipos pequeños son bastante típicos. Pero creo que somos diferentes y fuimos aún más lejos. Es poco probable que haya muchas compañías que emparejen la programación en tales números y que estén tan centradas en los desarrolladores.
Creo que esto se puede hacer en cualquier país, no se nos ocurrió un modelo desde cero: nos centramos en varias empresas, una de las cuales está en Chicago. Leímos algunos blogs, y sobre todo en Estados Unidos, vi un enfoque más cercano al nuestro.
Creo que el enfoque de los clientes inicialmente ayudó. Los salarios por hora son comunes en Estonia, puedes decir que ves tantas horas humanas, y juntos descubriremos cómo hacerlo lo mejor posible con el presupuesto disponible. En Estonia, esta idea no necesita ser vendida. Y, por ejemplo, en Rusia, la mayoría de las empresas clientes no están preparadas para esto, quieren pagar el proyecto, aunque al final para el cliente, por regla general, resulta más costoso.
- Al comienzo de la entrevista, se mencionó al cliente japonés. ¿Es esto típico? Cuando los clientes en el extranjero, e incluso aquellos con qué idiomas tiene que tratar?- Sobre Japón: sí, típicamente, Estonia trabaja mucho con los japoneses, vienen aquí como delegaciones enteras.
Nos comunicamos con casi todos los clientes en inglés, solo con ruso en ruso. No aceptan cambiar al inglés en absoluto, tal vez muchos podrían, pero son tímidos. Debido a esto, nos dimos cuenta de que tenemos desarrolladores especialmente valiosos que hablan ruso.
Y trabajamos con otros países en inglés, aunque los japoneses generalmente no son muy ingleses, pero los que llegan a Estonia para negociar generalmente hablan. E incluso dentro de Estonia a menudo nos comunicamos en inglés, porque en los últimos diez años ha sido muy cosmopolita, especialmente en TI. Muchos expertos vinieron de todo el mundo, por lo que casi siempre resulta que no todos los involucrados en el diálogo hablan estonio. Creo que esta es también la razón por la cual es bastante fácil mudarse a Estonia: lo principal es saber inglés, no se requiere estonio.
- Creo que, en teoría, a muchos desarrolladores les gustaría crear su propia empresa, pero temen no tener tiempo para programar y el cambio será para peor. ¿Qué muestra su experiencia de crear una empresa en Estonia?"Yo diría eso". Codeborne tiene aproximadamente nueve años, y durante ese tiempo, cuando alguien dejó la empresa, la mayoría de las veces para crear la suya. Por un lado, esto es insultante, porque crecimos y educamos a las personas, y por el otro, es halagador que la gente crea que el siguiente paso después de Codeborne puede ser solo eso.
Y diría que crear una empresa es una buena opción, pero esté realmente preparado para el hecho de que la mayoría de las veces (especialmente al principio) tendrá tareas que no están relacionadas con TI. « », , — .
, - . — , .
— — « ». , « »?— , flat-. « », , , — « ». , , , core team 10 , 30 - . .
— « »: ? ?— : . ( ), — . . : , , , .
— , - . ?— . , , , . Codeborne, — , , - . , ( ) , — , - . . .
Este fin de semana, Anton presentó la segunda serie de rompecabezas de Kotlin en Moscú en la conferencia de Mobius . Además de él, el programa también tiene muchas cosas interesantes para los desarrolladores móviles (por ejemplo, el informe "Kotlin para escribir código común para Android e iOS" ).
