Si quieres descubrir algo, aprende de los mejores. Hoy, mis preguntas son respondidas por el dios Corutin y la concurrencia, Roma elizarov Elizarov. Hablamos no solo de Kotlin, como podría pensar, sino también de varios temas relacionados:

• Golang y goroutines;
• JavaScript y su aplicabilidad para proyectos serios;
• Java y Project Loom;
• programación de olimpiadas en Kotlin;
• cómo aprender a programar correctamente;
• y otras cosas emocionantes

Kotlin: ¡bien hecho!

Hola Primero, algunas palabras sobre ti. ¿Has estado haciendo Kotlin durante mucho tiempo?

Tengo una larga historia con Kotlin. En 2010, Kotlin comenzó como un proyecto en JetBrains, donde no estaba trabajando en ese momento. Pero Max Shafirov (luego se involucró en Kotlin y fue uno de los iniciadores de este movimiento dentro de JetBrains) me invitó a convertirme en un experto externo y mirar el diseño y los comentarios. Inicialmente, el lenguaje fue diseñado para resolver sus problemas, porque JetBrains tiene su propia gran base de código Java, con problemas comprensibles que están constantemente presentes en el código, y quería hacer el lenguaje por mí mismo para que mi código pudiera escribirse de manera más agradable, eficiente y con menos errores. Solo lleva a cabo la modernización. Naturalmente, esto rápidamente se convirtió en la idea de que, dado que tenemos tales problemas, significa que otros tienen esos problemas, y necesitaban la confirmación de otras personas de que iban por el camino correcto.

Fui invitado como experto para mirar y comparar lo que está sucediendo con lo que se necesita. Acerca de la anulabilidad: insistí en que esto se hiciera, porque en ese momento era obvio para mí que si escribes en Java, hay muchos problemas, pero la anulabilidad es el principal problema que constantemente encuentras.

No participé en el trabajo del equipo, solo miré periódicamente, participé en competiciones en la Kotlin (Copa Kotlin). He estado compitiendo toda mi vida, pero aun así no participé activamente. Por ejemplo, no habría llegado a la final de competencias como la Facebook Hacker Cup, la forma no es la misma porque ya no participo en competencias de manera continua. Y participé en la Copa Kotlin y, dado que no atraía a una gran audiencia, llegué fácilmente a la final.

En ese momento (2012-2013), Kotlin era una vista triste desde el punto de vista del ajuste, porque todo se ralentizó allí. Desde entonces, el equipo ha hecho un gran trabajo. Me uní al equipo hace dos años, justo después del lanzamiento de 1.0 y antes de que Google reconociera oficialmente el idioma. Como equipo, tomé todo tipo de asincronía y corutinas, solo porque resultó que tenía la experiencia correcta, trabajé mucho en varios sistemas empresariales grandes diferentes en DevExperts, y hay mucha asincronía y comunicación. Por lo tanto, me imaginé bien las áreas problemáticas: lo que hay que arreglar y lo que lastima a las personas. Esto cayó muy bien en las necesidades de Kotlin, porque duele no solo con nosotros. Duele a todos. Incluso la JVM comenzó Project Loom, que, por así decirlo, insinúa que perjudica a todos. Todavía trato con las bibliotecas de Kotlin, y nuestro enfoque principal está en todo tipo de aplicaciones conectadas y asincrónicas.

Es decir, usted se dedica principalmente a bibliotecas, no a un compilador, ¿y eso es todo?

No, estoy haciendo el compilador en la medida en que. Me comunico con los chicos, y nuestro equipo de biblioteca prepara todos los alimentos que hacen en el compilador. También somos clientes, creamos muchas misiones de características cuando nos encontramos con algunas deficiencias, y somos probadores de la primera línea de todo lo nuevo que se implementa.

Resulta que si ingresas a YouTrack, filtra por ti, puedes encontrar muchas cosas interesantes.

Sí, puedes encontrar un montón de todo tipo de tareas, porque constantemente encuentro algo.

Mencionaste Project Loom. Fue hecho por el tipo que hizo Quasar. Por un lado, parece muy divertido, solo quería escribir un artículo sobre Habra sobre Loom. ¿Puedes decirme algo sobre él?

Vi una presentación, la idea es clara. Todos necesitan rutinas y programación asincrónica. Por ejemplo, en el pasado en JPoint, los muchachos de Alibaba contaron cómo piratearon la JVM y arruinaron el punto de acceso, simplemente rodando en un parche que ni siquiera escribieron, pero algunos muchachos antes que ellos. Más tarde aserraron debajo de sí mismos. Gran informe Lo recomiendo mucho

¿Recomiendas hacer esto?

Por eso es necesario hacerlo en las empresas. Cada gran empresa, por encima de un cierto tamaño, cuando varios miles de personas comienzan a trabajar para usted (y para alguien menos), mantiene su pirateo OpenJDK. Y, por supuesto, si tiene casos de usuarios críticos para el negocio, ¿por qué no hackear algo para usted? No veo ningún problema importante en esto. No es que lo recomiendo, pero tengo que hacerlo. Si no hay hilos ligeros en HotSpot, ¿qué debo hacer? Esto, de hecho, sugiere que las personas necesitan lo que está maduro. Y los comentarios que recibimos sobre las corutinas también dicen que sí, que está atrasado, la gente necesita transmisiones livianas, la gente necesita un carro de yuzkeys para transmisiones livianas. El hecho de que de alguna manera deberían ser compatibles con el JDK está retrasado desde hace mucho tiempo, y en este sentido no tengo dudas de que cuando Loom llegue a la producción tarde o temprano, tendrá demanda. Hay personas que lo necesitan. Hay personas que incluso por el bien de este parche HotSpot.

Vi un problema común: tienes algún tipo de servidor web, mucha gente lo golpea y comienza a bloquearse en los hilos.

Este es un problema bastante común. Y el servidor web, y el servidor de aplicaciones, y el backend. Si observa la misma presentación de Alibaba, por qué se necesitaba esta cosa, entonces no tienen un servidor web, tienen una arquitectura empresarial clásica, tienen todo tipo de servicios escritos en el backend de Java, estos servicios están bajo carga. Trabajé con DevExperts de la misma manera: los servicios están bajo carga, después de todo recibes solicitudes que no procesas: en el mundo moderno tienes todo conectado. Y no procesa esta solicitud usted mismo, pero llama al 100500 a todos los demás servicios y espera a que respondan. Y si estos servicios son lentos, entonces hay muchos hilos esperando. No puede permitirse el lujo de tener decenas de miles de estos flujos de espera. Y es solo por algunas tonterías que obtienes lo siguiente: un servicio que usas se ralentiza, y muchos hilos están de pie y esperando. Y ahora este es un problema muy grande.

Una de las razones por las cuales las personas migran a Go masivamente no es porque el idioma sea bueno, sino porque hay flujos livianos fuera de la caja, y no hay tal problema: las gorutinas pueden esperar y no cuestan nada. En el mismo Alibaba, la solución que implementaron es generalmente tonta de todas las estúpidas. No son muy ligeros en el sentido de que asignan una gran pila de 2 megabytes a cada rutina, pirateando HotSpot para que estas pilas puedan cambiarse. Ahorran flujo físico, pero no guardan pilas. Y para ellos, la solución funciona: por cierto, es muy simple, tienen un parche HotSpot, según tengo entendido, no muy grande. Los chicos de Loom comenzaron algo más global. Decidieron ahorrar no solo en transmisiones físicas, sino también en la pila, para no gastar 2 megabytes por transmisión. En el prototipo, la pila actual pasa a través de HotSpot, se copia en una pequeña estructura de cadera. Y pueden reutilizar esta pila física para otros fines.

Pero hay un truco tan astuto: cuando vuelves al rendimiento, no lo copian todo, sino solo lo mejor.

Sí, hay autos de hacks y optimizaciones. Lo que finalmente resulta es muy difícil de decir. Porque en el ejemplo del enfoque con la copia, surge el siguiente problema de inmediato: ¿qué hacer con las llamadas nativas? Desde dentro de la llamada nativa, ya no puede copiar la pila de la llamada nativa. El enfoque de Alibaba no tiene ese problema. Nativo, no nativo: cuál es la diferencia, simplemente desenganchó esa pila por completo y la dejó sola, recogió otra pila, todo funciona. Y es demasiado pronto para decir si tendrá éxito o no, a veces puedes vivir con esta pila nativa, a veces no puedes; en esta etapa es demasiado temprano para decirlo. Por ejemplo, cómo se implementa en Go es un mecanismo completamente diferente. Mientras ejecuta código gosh, se utilizan pequeñas pilas de gosh. Por consiguiente, cuando un tiempo de ejecución de Gosh llama a una función, analiza cuánto necesita la pila. Si la pila actual no es suficiente, se reasigna - aumenta el tamaño de la pila seleccionada. Si, en consecuencia, realiza una llamada nativa, entonces ya toman una gran pila nativa de un determinado grupo y la usan.

¿Y también para el código de Dios?

No importa Simplemente pueden cambiar a una gran pila nativa si necesita llamar a alguna función externa, para lo cual no está claro cuánto se necesita una pila. Y cuando ejecuta el código Gosh, sabe cuántas pilas se necesitan, por lo que podemos ejecutarlo en una pila pequeña. Este es un enfoque completamente diferente. No copie, pero ejecute inmediatamente en una pila pequeña. De hecho, no hay mucha diferencia entre estos enfoques hasta que te quedes dormido ocasionalmente.

Constantemente nos hacen la pregunta: “¿Qué es más rápido? ¿Qué es lo adecuado? ¿Cómo lo haces en las corutinas? Nosotros en las rutinas no pirateamos la JVM. Nuestro objetivo es que esto funcione bajo la JVM normal. Y para que Android también funcione. Existe su propio ART, que tampoco sabe nada sobre las corutinas. Y así, naturalmente, tenemos que generar bytes con plumas, lo que hace algo muy similar a copiar la pila que hace Loom, solo que lo hacemos en bytecode. Lo tomamos cuando ya es tarde. Tome una pila, relájese y copie a la cadera. No estamos en un tiempo de ejecución que haría esto por nosotros, hemos generado un código de bytes que hace esto. Conserva y restaura el estado de la rutina. Debido al hecho de que no hacemos tiempo de ejecución, por supuesto, tenemos más sobrecarga de esto. En tiempo de ejecución puedes hacer todo más rápido. Por otro lado, si usa corutinas para la programación asincrónica, entonces necesita quedarse dormido, si dejó de esperar una respuesta de algún servicio, y enviar una solicitud a algún servicio es tan costoso que toda la sobrecarga al copiar la pila no molesta a nadie en absoluto. ya sea lento o rápido, no importa en absoluto. Sí, si lo usa específicamente para programación asincrónica. En las rutinas en Kotlin, se escala notablemente, como se muestra en el prototipo Project Loom.

Otra diferencia es que dado que en Kotlin estamos obligados a hacer esto en bytecode, tenemos un efecto secundario tan interesante. Por un lado, parece no tener éxito, y por el otro, por el contrario. Consiste en lo siguiente: es imposible sacrificar una función arbitraria. Necesita funciones que puedan conciliar el sueño, suspender la marca con el modificador; tenga en cuenta explícitamente que la función puede pausar y esperar a que algo sea largo. Por un lado, no necesitas esto en Loom, porque el tiempo de ejecución puede poner cualquier cosa a dormir. La solución de Alibaba es la misma: puede tomar una pila de cualquier hilo. O en Go: todo se puede encerrar allí, cualquier código puede quedarse dormido. Rellene gorutin y hágalo. Por un lado, este enfoque es muy similar a la programación con hilos. Es como si estuvieras programando como antes, solo que ahora los hilos se llaman fibra y se han vuelto muy baratos. Si observa cuidadosamente la presentación del mismo Loom, resulta que la fibra y los hilos siguen siendo cosas diferentes. Cómo asegurarse de que el antiguo código que está escrito con hilos termina completamente fuera de la caja en las fibras, no es obvio y en qué tendrán éxito, nadie lo sabe. Los problemas comienzan allí: qué hacer con los puntos muertos, qué hacer con el código que está optimizado para locales de subprocesos, nuevamente algunos hashes locales o id de subproceso hacen algunas optimizaciones de rendimiento. Y Go tiene el mismo problema: cuando las ID de hardware no están expuestas, escribir algún tipo de algoritmo de alto rendimiento no es trivial.

Pero en Kotlin esto no es?

En Kotlin, no estamos tratando de fingir que el hilo y la fibra son lo mismo. Ni siquiera tratamos de ejecutar el código anterior, no tenemos esa tarea en principio. Decimos: "Lo siento, porque no somos tiempo de ejecución, no podemos tomar arbitrariamente el antiguo código Java y comenzar a cambiar algo allí". Y ni siquiera lo intentaremos. Tenemos una tarea diferente. Decimos que tenemos una característica del lenguaje, funciones para conciliar el sueño, puede escribir código asincrónico con ellos, y esta es una nueva característica del lenguaje. Y nos distanciamos completamente de este problema ("cómo ejecutar el código antiguo"), decimos: "Hay un código nuevo, bueno, ortodoxo, puedes ponerlo a dormir". Hasta cierto punto, esto hace la vida más fácil, porque no tienes que elevarte ni a ti mismo ni a las personas, pero qué sucede si algún viejo govnokod que no sabía que lo lanzarían sobre las fibras se lanzaría sobre ellos de repente.

En nuestro modelo, no tenemos ningún código antiguo, solo uno nuevo, que inicialmente está listo para el hecho de que hoy está en un hilo, mañana en otro, y si, por ejemplo, necesita averiguar qué hilo es ahora, lo sabrá. Sí, necesitas un hilo local, pero él puede reconocerlos. Sin embargo, debe estar preparado para el hecho de que hoy en día los locales son uno y mañana, otros. Si quiere que estos lugares viajen con él, hay otro mecanismo para esto, un contexto de rutina donde puede almacenar sus cosas, que, junto con la rutina, viajarán de hilo en hilo. Esto, en cierto sentido, nos facilita la vida, porque no estamos tratando de mantener el código antiguo.

Y, por otro lado, hacemos que una persona piense explícitamente sobre su API, digamos: aquí estoy escribiendo una función en Kotlin con corutinas. Si antes miro algún método en mi código, obtengo lo que no está claro, este método funciona rápidamente y regresa de inmediato o se conecta y puede funcionar durante una hora. Solo puedo leer la documentación y entender lo rápido que funcionará. O tal vez está trabajando rápido ahora, y mañana el programador Vasya Pupkin vendrá y lo pondrá en línea ahora. Con Kotlin Coroutines, proporcionamos un mecanismo garantizado por el idioma con un modificador de suspensión . Cuando trabajo con corutinas, miro alguna función, si no veo el modificador de suspensión, significa que funciona rápidamente, hace todo localmente. Hay un modificador de suspensión, lo que significa que esta función es de alguna manera asíncrona, irá a la red durante mucho tiempo. Y ayuda a hacer una API autodocumentada para que podamos ver de inmediato lo que nos espera. Esto ayuda a evitar de inmediato errores estúpidos cuando olvidé en algún lugar y en algún lugar del código que llamé a algo largo sin sospecharlo.

En la práctica, esto es muy bueno. Esta necesidad de marcar explícitamente estas funciones para conciliar el sueño. En Go, por ejemplo, esto no es así, no tengo que marcar nada por ahí. Resulta que este efecto secundario de nuestra implementación (que debe marcarse con el modificador de suspensión) te ayuda a hacer que la arquitectura sea correcta, te ayuda a controlar que no causarás un juego asincrónico aleatorio en el lugar donde inicialmente esperabas que todo sucediera rápidamente.

Pero hay algunas cosas que son difíciles de prohibir, por ejemplo, algún tipo de red IO, archivo.

No, la red IO solo lo prohíbe con bastante facilidad. Aquí está el archivo IO - complicado. Pero aquí nuevamente, un punto delicado: para la mayoría de las aplicaciones, el archivo IO es algo rápido y, por lo tanto, es perfectamente normal que funcione sincrónicamente. Una aplicación muy rara funciona tanto con IO que se convierte en un problema que demore tanto. Y aquí le damos a una persona la oportunidad de elegir: puede hacer directamente un archivo IO con nosotros y no tomar un baño de vapor, porque bloqueará lo que está sucediendo (porque generalmente es rápido). Pero si su caso particular solo tiene un cálculo muy largo, no es asíncrono, pero solo consume mucho tiempo de CPU y no desea bloquear algunos de sus otros grupos de subprocesos, proporcionamos un mecanismo simple y comprensible: inicia un proceso separado grupo de subprocesos para su computación pesada, y en lugar de escribir una función regular que sea divertida computeSomething () , y escribir en la documentación "Dudes, cuidadosamente, esta función puede funcionar durante mucho tiempo, así que atención , no la uses en ningún lado, no la uses UI ", ofrecemos un método más simple Janismo. Simplemente escriba esta función como suspender fun computeSomething () , y para su implementación utiliza una función de biblioteca especial con Contexto , que arroja el cálculo al grupo de hilos especial que especificó. Esto es muy conveniente: el usuario ya no necesita volar el cerebro: inmediatamente ve una suspensión, sabe que esta llamada no bloquea su hilo, y puede llamarla fácilmente desde un flujo de interfaz de usuario, etc.

Cambiará a la secuencia deseada que ya está dentro, y su secuencia no será bloqueada. Esta es la separación correcta de preocupaciones: al usuario no le importa cómo se implementa, pero el que implementa puede transferir correctamente al grupo al que se necesita y distribuir correctamente los recursos informáticos en su aplicación. En la práctica, esto demuestra ser muy conveniente en términos de estilo de programación. Necesitamos escribir menos documentación, el compilador verificará y corregirá más.

Pienso lo seguro que es. ¿Alguien puede romper un grupo de subprocesos o entrar en los datos de otra persona?

Naturalmente, todo es posible. Es difícil protegerse de las manos torcidas. Está claro que no importa cuánto escribamos todo tipo de sistemas de tipos y verificaciones en el compilador, siempre se puede romper todo. La pregunta es que el compilador debería ayudar a escribir el código correcto. Desafortunadamente, el sueño de prohibir el mal código es utópico. Específicamente, no incluimos ninguna función en el idioma. No hay cosas de Java en Kotlin si se sabe de ellas que se usan principalmente para otros fines y el código con ellas es mayormente malo. Pero cualquier buena característica que se encuentre en Kotlin se puede usar para otros fines en una gran cantidad de formas diferentes. No hay opciones, desafortunadamente. Se puede abusar del lenguaje de muchas maneras diferentes. No puedes protegerte de las manos torcidas.

Aprendí de los estudiantes de Kotlin qué pregunta interesante puedes hacer. Se rindieron y dijeron que usted es muy astuto y evade sus preguntas con flexibilidad.

¿De qué preguntas?

Por ejemplo, una pregunta sobrevivió a dos personas: ¿por qué en Kotlin no hay tipos sin procesar? Sin genéricos.

Porque siempre puedes escribir un asterisco.

¿Y será compatible con Java?

Si

Es decir, tiene algún tipo de método java que requiere algo sin un genérico. Lista, por ejemplo.

Si existe un método de Java sin un genérico, puede pasar cualquier Lista allí. Puede transferir la Lista con un asterisco, puede hacerlo con una cadena. Kotlin te permitirá transferir cualquier juego al método Java. raw List, platform type, , , List . raw type, , Java , . Java, , , , , , raw type. , — , . , — . — , , raw types. , migration story.

platform type ?

flexible. nullable-. , String. , String nullable String — . , String — nullable -nullable. Kotlin , , . String, nullable String. , - Java, .

?

, , , , . Flexible , dynamic. Flexible — , Java, String, nullable String, int.

- - , .

, , . . read only mutable. List MutableList. Java List, , Java- , , - List MutableList. , Java. , Java - , . , , . , , , List, , , MutableList, List . List, String, .

- , ? - ?

, . , . It just works. Java . nullability- , , nullable . , . , , , . , , , , - . , -. - JavaFx, - , JavaFx Java, , . , - , . . , , .

, .

Por supuesto , . Kotlin Native. : , seamless C- , , - .

, Native ?

, , Kotlin JavaScript, - - . «Write once, run anywhere», , . : , Common Kotlin Portable Kotlin, , . , - - , , . , , - . , .

JVM , Java, JS , JS, Native . , , , , . - JS, . -. - : double, String. JVM- 0 «0.0», JS . . JS , , — ? , . , , JS- . , -. , . - — , , — . , , , , JVM, JS, Native — , , - . .

?

. , , .

, …

, . , . Loom . - JVM. , .

, , Java?

, . . — . , . , - . , for ( i in 0..10 ) , for (int i = first . , , . . , .

- ?

, … , . . JVM JS.

Node.js?

! . , JS-. , , JS- . , . , - — , JS-, - — . , . .

« ». , ?

Por supuesto , , . JVM , Java, . JVM . legacy, enterprise, . , , . , JVM. , — , . , . , — JVM « ». . API , . , . , . , , . , , .

TechTrain « ?» . . , .

JS , Kotlin Java?

Java . «Kotlin in Action», , Java-. , Java- , , Kotlin-. , «by design». , Java- . . JPoint , Kotlin . , . , 60-70% Java. Java, , - . Java .

- — , , -. as-is. , , . Kotlin , , «», «». , «» — . while — . 100500 . Pero por que? , Java-. - , « Kotlin», , .

, . . , , . , .

, -, ?

, . . Java- . Android- — , . . , . — .

- , ?

, . , , . , , . — , , . Kotlin . , . - , , , . : , . C++, Java, Python. . Java - , Java, . , , puiblic static void main… -, . Java, , . ?

Kotlin : , , Python, . C++ , C++ . , , . , . , , . Kotlin — . — Python. . . , . , . . — , , , , — . , .

, — ?

, . must have. , — . . , . — . , , , .

?

… , , . . JS- — . — . JS, , . - JS, type checkers, Flow TypeScript. - JS . Python. - DSL, . Django , . , . , , , . . Django, , CRUD-. , - — . -, - , , . . . Kotlin, , Java, . core belief Kotlin, .

, - , Kotlin ?

Por supuesto! , , - CRUD-. : , , — , . -, — , . , TypeScript Flow — JS.

Kotlin , Kotlin JS TypeScript , . TS Kotlin/JS, , TS , JS-, . Kotlin/JS , . , .

, — double…

, . , , .

- .

.

?

Tengo olimpiadas :-) Y yo mismo participo, pero rara vez.

Solo veo que en los Juegos Olímpicos, Java a veces está disponible como uno de los idiomas principales.

Ahora está disponible casi siempre. Ella apareció hace unos quince años. Java y C ++ son dos lenguajes estándar que admiten todos, y luego variaciones, según la competencia.

¿Es más difícil ganar en Java? ¿Hay gastos generales ocultos?

Depende de la competencia. En una competencia normal, es lo mismo si hay más tareas en la idea y el algoritmo correcto. Pero hay algún tipo de juego cuando las tareas implican una optimización no asintótica, donde necesitas optimizar todo al ritmo; allí, por supuesto, será difícil en Java, tendrás que intentar mucho. Además, hay un tiempo de espera de prueba muy corto. En términos generales, si tiene un límite de tiempo de ejecución de unos segundos, HotSpot se calienta en un código pequeño en un segundo y no le importa. Y si tiene un límite en todo, un segundo, entonces en Java simplemente puede perder debido al hecho de que mientras HotSpot se está calentando y compilando, ha pasado un segundo.

Sí, hay competiciones salvajes donde Java es difícil. Pero las competencias normales (populares, respaldadas por buenas personas): intentan hacer las tareas y el entorno de tal manera que Java y las ventajas tengan las mismas oportunidades. Y las razones son claras: aunque Java no crece en educación, no disminuye mucho en ninguna parte. En algún lugar, algunas universidades se negaron a aprender Java y cambiaron a Python, y debido a esto, incluso, ahora muchas competiciones han aprendido Python. Este es un tercer idioma tan estable compatible. Las competiciones son principalmente de estudiantes. Hay competiciones profesionales, y las grandes empresas están haciendo algo como la Hacker Cup de Facebook, donde todos pueden participar, pero aún así, el tema principal en la programación deportiva es la escuela y los estudiantes. En los años escolares y estudiantiles, las personas se realizarán y entrenarán constantemente. Pero después de la graduación, después de ir a trabajar, muy pocas personas continuarán participando. Por lo tanto, la elección de los idiomas está determinada por lo que se usa en la educación. Si enseñan más, Java y Python, estarán en las competiciones. Para muchos programadores, Java es el primer idioma, respectivamente, todas las competiciones intentan admitir Java. En aras de la competencia para aprender C ++ - juego. Es para la programación del sistema, la programación de bajo nivel, no necesita tener un millón de programadores de C ++, no tiene sentido en absoluto.

¿Qué le parece la idea de agregar Kotlin a la lista de idiomas estándar?

Bueno, en realidad, estamos promoviendo activamente esta idea. Hay un ICPC que se realiza anualmente, reúne a cientos de miles de participantes en todo el mundo, más de cien equipos van a la final. En ICPC, Kotlin es compatible. Ahora hay una lista de lenguajes: C / C ++, Java, Python y Kotlin. Pero por ahora, por supuesto, nadie realmente escribe sobre él, por la razón de este problema: penetración en la educación en una etapa muy temprana. En las competencias de los estudiantes, se usan esos idiomas que se les enseña a los estudiantes.

¿Kotlin ya se enseña en alguna parte?

En algún lugar exactamente enseñado. Por ejemplo, en el Politécnico de San Petersburgo. Pero estamos en una etapa muy temprana, en el "paso 0" de este proceso.

No hay fallas fatales?

No, Kotlin es mejor para la educación primaria que otros idiomas. La educación justa es conservadora. La gente tiene un programa listo, libros de texto. A nadie le gusta el cambio. ¿Por qué un profesor que enseña programación en su primer año de estudiantes cambiaría su idioma, cuál es la ventaja? Esto puede revisarse cada diez años.

La ventaja, por ejemplo, es que la persona que lo abandona estará más adaptada a la realidad.

No Porque no es tan importante qué idioma aprendiste primero. Un programador profesional en su vida ha estudiado una docena de idiomas y usa activamente cerca de tres idiomas. Además, todo esto está cambiando constantemente. Lo que se le enseñará a programar primero no es tan importante. Es importante la cantidad de idioma que tiene al graduarse de una universidad; este es otro tema, esto es importante. Y aquí nos enfrentamos a problemas en mercados conservadores que se centran en la autoridad. Por ejemplo, en China hay un problema que se aclara después de hablar con los muchachos de allí. Usted toma cualquier oficina grande en la que haya muchos programadores, pregunta: ¿por qué no usa Kotlin? Pero porque ahora, los muchachos no enseñaban Kotlin en la universidad, y no quieren aprender nada nuevo, pero ¿por qué lo harían?

¿No es así con nosotros?

Esto está en todas partes, solo en una escala diferente. En diferentes culturas de diferentes maneras. Hay culturas en las que, como dijo el gurú, o como dijo el maestro, lo harás. En algún lugar, las personas son más independientes, más propensas a la experimentación, la innovación. En algún lugar la gente irá y aprenderá todo por sí misma. En algún lugar no levantarán un dedo y harán exactamente lo que se les enseñó. Hay más implementaciones de Kotlin en Rusia, pero esto también se debe a que somos originarios de aquí, hablamos más en conferencias, etc.

Esto es en mi generación, los programadores han sido entusiastas. Crecí cuando los que les gustaba programaron, estudiaron todo por su cuenta, porque no había nada. Y ahora esto es lo masivo que se está enseñando. Tomemos un programador moderno, la mayoría no hace esto porque ama, sino porque le enseñaron esto y ahora pagan mucho dinero. En consecuencia, esas personas no estudiarán la tecnología que se acaba de lanzar. ¿Por qué lo necesitan?

Porque ganarás mucho dinero con las fantásticas funciones de esta tecnología.

Por supuesto que no! En Kotlin, es más probable que obtenga más placer.

Hay cosas específicas que realmente tienen valor comercial: hablamos sobre la reutilización entre el frente y la parte posterior ...

No todos lo necesitan. Por otro lado, y placer también. No todos disfrutan de su trabajo en absoluto. Se les paga dinero; trabajan, no les importa si disfrutan o no. La jornada laboral terminó: cerraron y lo olvidaron, y comenzaron a hacer otras cosas.

Esto es de alguna manera muy aburrido, si no terrible.

Esta es la verdad de la vida, desafortunadamente. No importa cuán terrible sea ella. Y a esas personas, por supuesto, no les importa. Kotlin, no Kotlin.

Por lo que entiendo, solo mucha gente trabaja en JetBrains porque les gusta trabajar.

JetBrains a este respecto es una muestra no representativa, por supuesto. Personas especialmente seleccionadas, motivadas, que realmente les gusta esta cosa.

Nuestro tiempo está llegando a su fin lentamente, por lo que la pregunta es: ¿pueden pasar algo a nuestros lectores sobre Habré? ¿Alguna palabra de despedida, alguna revelación?

Puedo transmitir saludos ardientes :-) Pero no diré ninguna revelación, ¿qué tipo de revelación puede ser? La única conclusión que se puede extraer de nuestra conversación es que quien disfruta del trabajo es feliz. Leí varios blogs de buenas personas que programaron en Java, simplemente trabajaron sin ningún placer. Y luego, por alguna razón, se volvieron curiosos, la vida los hizo, probaron Kotlin e inesperadamente descubrieron por sí mismos que puedes disfrutar trabajando. Que puedes amar lo que haces. Lo que puedes amar es un lenguaje de programación. Y no solo para usar, sin emoción, como herramienta. Por supuesto, el lenguaje es una herramienta, pero puedes relacionarte con él indirectamente o puedes amarlo. Esta es una actitud diferente, que incluye una actitud diferente hacia el trabajo.

Kotlin tiene muchas personas que tienen sentimientos cálidos comparables al amor, precisamente porque Kotlin es agradable de programar, especialmente después de Java. Quizás no solo después de Java. Probablemente no haya idiomas en los que sea tan agradable (solo una palabra) programar. Hay idiomas con más funcionalidad, con características más fuertes, hay idiomas con un sistema de tipos más estricto, hay idiomas donde todo es puro, hay donde todo es viceversa, inseguro. Tome cualquier dimensión y encontrará idiomas que son mejores que Kotlin en esta propiedad. Pero Kotlin tiene un equilibrio tal que no es casualidad que él en StackOverflow en la encuesta de este año haya sido el segundo en la lista de los idiomas más queridos. El primero, al parecer, fue Rust. Pero Rust no es un competidor para nosotros, porque Rust es un lenguaje de programación del sistema. No subimos a este nicho. No es en absoluto molesto que Rust a este respecto haya superado a Kotlin. Nos esforzamos por hacer de Kotlin el lenguaje principal para la programación de aplicaciones en el que es agradable resolver problemas de aplicaciones. No tenemos y nunca tendremos algunas características de Rust, porque simplemente no las necesita el programador de la aplicación. No debe administrar manualmente la memoria ni pensar en las complejidades de la propiedad, un programador de aplicaciones debe resolver los problemas comerciales. Debe transformar su dominio en código. Y esta debería ser la transformación más directa sin ningún factor que interfiera con ella. Estamos tratando de eliminar estos factores interferentes. Para que pueda transformar su tarea empresarial de la forma más directa posible, sin agua ni código adicional, en una solución.

Bueno, esta es una competencia un tanto injusta: todos estos lenguajes como Java se inventaron hace muchos años, y usted acaba de hacerlo.

Naturalmente, Kotlin tiene en cuenta la experiencia de sus predecesores. Como cualquier lenguaje moderno. Esto es progreso: cuando se crea algo nuevo teniendo en cuenta las deficiencias antiguas. Por una buena razón, los tipos anulables se fabrican en Kotlin. Bueno, vaya lejos, tome cualquier empresa, vaya a cualquier oficina grande, mire sus registros de fallas y verá que la excepción más frecuente es NullPointerException. Este es un hecho bien conocido, y si está creando un nuevo idioma, debe resolverlo. Por lo tanto, prestamos mucha atención en el lenguaje a la nulabilidad. Y así sucesivamente. Si no diseña el lenguaje de manera abstracta, no como un ejercicio académico, pero trata de resolver los problemas de las personas que a menudo encuentran, entonces el lenguaje resulta ser bueno. ¿Por qué es amado? Porque él resuelve sus problemas.