Si vous voulez comprendre quelque chose, apprenez du meilleur. Aujourd'hui, le dieu Corutin et la concurrence, Roma elizarov Elizarov, répondent à mes questions. Nous avons parlé non seulement de Kotlin, comme vous pourriez le penser, mais aussi d'un tas de sujets connexes:

• Golang et goroutines;
• JavaScript et son applicabilité pour les projets sérieux;
• Java et Project Loom;
• programmation olympiade sur Kotlin;
• comment apprendre la programmation correctement;
• et d'autres choses passionnantes.

Kotlin - bravo!

Salut Tout d'abord, quelques mots sur vous. Vous faites du Kotlin depuis longtemps?

J'ai une longue histoire avec Kotlin. En 2010, Kotlin a commencé comme projet chez JetBrains, où je ne travaillais pas à l'époque. Mais Max Shafirov (il était alors engagé dans Kotlin et était l'un des initiateurs de ce mouvement au sein de JetBrains) m'a invité à devenir un expert externe et à regarder la conception et le commentaire. Initialement, le langage a été conçu pour résoudre ses problèmes, car JetBrains a sa propre grande base de code Java, avec des problèmes compréhensibles qui sont constamment présents dans le code, et je voulais créer le langage pour moi afin que mon code puisse être écrit plus agréablement, efficacement, avec moins d'erreurs. Effectuez simplement la modernisation. Naturellement, cela est rapidement devenu l'idée que puisque nous avons de tels problèmes, cela signifie que d'autres ont de tels problèmes, et ils avaient besoin de la confirmation d'autres personnes qu'ils allaient dans le bon sens.

J'ai été invité en tant qu'expert pour regarder et comparer ce qui se passe avec ce qui est nécessaire. À propos de la nullité - J'ai insisté pour que cela soit fait, car à ce moment-là, il était évident pour moi que si vous écrivez en Java, il y a beaucoup de problèmes, mais la nullité est le principal problème que vous rencontrez constamment.

Je n'ai pas participé au travail de l'équipe, j'ai juste jeté un coup d'œil périodiquement, participé à des compétitions à la Kotlin (Kotlin Cup). J'ai concouru toute ma vie, mais même alors, je n'ai pas participé activement. Par exemple, je n'aurais pas atteint la finale de compétitions comme la Facebook Hacker Cup, la forme n'est pas la même car je ne participe plus aux compétitions de façon continue. Et j'ai participé à la Coupe Kotlin et, comme elle n'a pas attiré un large public, j'ai facilement atteint la finale.

A cette époque (2012-2013), Kotlin était un triste spectacle du point de vue du tuning, car tout y ralentissait. Depuis lors, l'équipe a fait un excellent travail. J'ai rejoint l'équipe il y a deux ans, juste après la sortie de la version 1.0 et avant que Google ne reconnaisse officiellement la langue. En équipe, j'ai pris toutes sortes d'asynchronies et de coroutines, simplement parce qu'il s'est avéré que j'avais la bonne expérience, j'ai beaucoup travaillé dans différents systèmes de grandes entreprises chez DevExperts, et il y a beaucoup d'asynchronie et de communication. Par conséquent, j'ai bien imaginé les problèmes - ce qui doit être corrigé et ce qui fait mal aux gens. Cela répondait très bien aux besoins de Kotlin, car cela fait mal non seulement avec nous. Ça fait mal à tout le monde. Même la JVM a lancé Project Loom, ce qui, pour ainsi dire, laisse entendre que cela fait du mal à tout le monde. Je travaille toujours avec les bibliothèques Kotlin, et notre objectif principal est de toutes sortes d'applications connectées et asynchrones.

Autrement dit, vous êtes principalement engagé dans les bibliothèques, pas un compilateur, et c'est tout pour ça?

Non, je fais le compilateur dans la mesure où. Je communique avec les gars et notre équipe de bibliothèque préfigure tout ce qu'ils font dans le compilateur. Nous sommes également des clients, nous créons beaucoup de quêtes de fonctionnalités lorsque nous rencontrons des lacunes, et nous testons la première ligne de tout ce qui est nouveau.

Il s'avère que si vous allez dans YouTrack, filtrez par vous, vous pouvez trouver beaucoup de choses intéressantes.

Oui, vous pouvez trouver un tas de tâches de toutes sortes, car je rencontre constamment quelque chose.

Vous avez mentionné Project Loom. Il a été fait par le gars qui a fait Quasar. Du côté, ça a l'air très drôle, je voulais juste écrire un article sur Habra à propos de Loom. Pouvez-vous me parler de lui?

J'ai vu une présentation, l'idée est claire. Tout le monde a besoin de coroutines et d'une programmation asynchrone. Par exemple, dans le passé chez JPoint, les gars d'Alibaba ont raconté comment ils avaient piraté la JVM et gâché le hotspot, juste en introduisant un patch qu'ils n'avaient même pas écrit, mais certains gars avant eux. Ils ont ensuite scié sous eux-mêmes. Excellent rapport. Je le recommande vivement.

Recommandez-vous cela?

Il faut donc faire dans les entreprises. Chaque grande entreprise, au-dessus d'une certaine taille, lorsque plusieurs milliers de personnes commencent à travailler pour vous (et pour quelqu'un de moins), maintenez votre hack OpenJDK. Et bien sûr, si vous avez des cas d'utilisateurs critiques, alors pourquoi ne pas pirater quelque chose par vous-même, je ne vois pas de gros problème là-dedans. Non pas que je le recommande, mais je dois le faire. S'il n'y a pas de threads légers dans HotSpot, que dois-je faire? En fait, cela suggère que les gens ont besoin de ce qui est mûr. Et les commentaires que nous obtenons sur les coroutines indiquent également que oui, il est grand temps, les gens ont besoin de flux légers, les gens ont besoin d'un wagon de yuzkeys pour les flux légers. Le fait qu'ils devraient en quelque sorte être pris en charge dans le JDK est attendu depuis longtemps, et dans ce sens, je ne doute pas que lorsque Loom arrivera tôt ou tard en production, il sera demandé. Il y a des gens qui en ont besoin. Il y a des gens qui, même pour le plaisir de ce patch HotSpot.

J'ai vu un problème commun - vous avez une sorte de serveur Web, beaucoup de gens y frappent et il commence à se bloquer sur les threads.

Il s'agit d'un problème assez courant. Et le serveur Web, le serveur d'applications et le backend. Si vous regardez la même présentation d'Alibaba, pourquoi cette chose était nécessaire, alors ils n'ont pas de serveur Web, ils ont une architecture d'entreprise classique, ils ont toutes sortes de services écrits sur le backend Java, ces services sont sous charge. J'ai travaillé avec DevExperts de la même manière: les services sont sous charge, vous recevez des demandes que vous ne traitez pas après tout - dans le monde moderne, vous avez tout connecté. Et vous ne traitez pas cette demande vous-même, mais vous appelez 100500 tous les autres services et attendez qu'ils répondent. Et si ces services sont lents, vous avez beaucoup de threads en attente. Vous ne pouvez pas vous permettre d'avoir des dizaines de milliers de ces flux d'attente. Et c'est juste à cause de certaines absurdités que vous obtenez ce qui suit: un service que vous utilisez ralentit et beaucoup de threads sont debout et attendent. Et maintenant, c'est un très gros problème.

L'une des raisons pour lesquelles les gens migrent massivement vers Go n'est pas parce que la langue est bonne, mais parce qu'il y a des flux légers hors de la boîte, et il n'y a pas un tel problème: les goroutins peuvent attendre et ils ne coûtent rien. Dans le même Alibaba, la solution qu'ils ont mise en œuvre est généralement stupide de toutes les stupides. Ils ne sont pas très légers dans le sens où ils allouent une grande pile de 2 mégaoctets à chaque coroutine, piratant HotSpot pour que ces piles puissent être commutées. Ils économisent le flux physique, mais pas les piles. Et pour eux, la solution fonctionne - au fait, c'est très simple, ils ont un patch HotSpot, si je comprends bien, pas très gros. Les gars de Loom ont commencé quelque chose de plus global. Ils ont décidé d'économiser non seulement sur les flux physiques, mais également sur la pile, afin de ne pas dépenser 2 mégaoctets par flux. Dans le prototype, la pile actuelle passe par HotSpot, elle est copiée dans une petite structure de hanche. Et ils peuvent réutiliser cette pile physique à d'autres fins.

Mais il y a un hack si rusé: quand vous revenez à la performance, ils ne copient pas tout, mais seulement le top.

Oui, il y a des voitures de hacks et d'optimisations. Ce qui en ressort finalement est très difficile à dire. Parce que sur l'exemple de l'approche avec la copie, le problème suivant se pose immédiatement: que faire des appels natifs? Depuis l'appel natif, vous ne pouvez plus copier la pile de l'appel natif. L'approche d'Alibaba n'a pas un tel problème. Native, not native - quelle est la différence, vous venez de décrocher complètement cette pile et de la laisser seule, de prendre une autre pile, tout fonctionne. Et il est trop tôt pour dire si cela réussira ou non, parfois vous pouvez vivre avec cette pile native, parfois vous ne pouvez pas - à ce stade, il est trop tôt pour le dire. Par exemple, la façon dont il est implémenté dans Go est un mécanisme complètement différent. Pendant que vous exécutez le code gosh, de petites piles gosh sont utilisées. Par conséquent, lorsqu'un runtime gosh appelle une fonction, il regarde combien la pile a besoin. Si la pile actuelle n'est pas suffisante, elle réalloue - augmente la taille de la pile sélectionnée. Si, en conséquence, vous effectuez un appel natif, alors ils prennent déjà une grosse pile native d'un certain pool et l'utilisent.

Et pour le code gosh aussi?

Peu importe. Ils peuvent simplement basculer vers une grande pile native si vous avez besoin d'appeler une fonction externe, pour laquelle il n'est pas clair combien une pile est nécessaire. Et lorsque vous exécutez le code gosh, vous savez combien de piles sont nécessaires, afin que nous puissions l'exécuter sur une petite pile. Il s'agit d'une approche complètement différente. Ne copiez pas, mais exécutez immédiatement sur une petite pile. En fait, il n'y a pas beaucoup de différence entre ces approches jusqu'à ce que vous vous endormiez occasionnellement.

On nous pose constamment la question: «Qu'est-ce qui est plus rapide? Qu'est-ce qui convient? Comment faites-vous dans les coroutines? " En coroutines, nous ne piratons pas la JVM. Notre objectif est que cela fonctionne sous la JVM normale. Et pour qu'Android fonctionne aussi. Il y a son propre ART, qui ne sait rien non plus des coroutines. Et donc, naturellement, nous devons générer des octets avec des stylos, ce qui fait quelque chose de très similaire à la copie de la pile que Loom fait, seulement nous le faisons en bytecode. On le prend quand il est déjà tard. Prenez une pile, détendez-vous et copiez sur la hanche. Nous ne sommes pas sur un runtime qui ferait cela pour nous, nous avons généré un bytecode qui fait cela. Il préserve et restaure l'état de la coroutine. En raison du fait que nous ne faisons pas d'exécution, bien sûr, nous avons plus de frais généraux de cela. En runtime, vous pouvez tout faire plus rapidement. D'un autre côté, si vous utilisez des coroutines pour la programmation asynchrone, vous devez vous endormir, si vous êtes parti pour attendre une réponse d'un service et envoyer une demande à un service est si cher que tout le surcoût de copie de la pile ne dérange personne du tout - que ce soit lent ou rapide, cela n'a pas d'importance du tout. Oui, si vous l'utilisez spécifiquement pour la programmation asynchrone. Sur les coroutines de Kotlin, il évolue remarquablement, comme le montre le prototype du projet Loom.

Une autre différence est que, comme nous, à Kotlin, sommes obligés de le faire en bytecode, nous avons un effet secondaire très intéressant. D'une part, elle semble infructueuse, et d'autre part, au contraire. Elle consiste en ce qui suit: il est impossible d'euthanasier une fonction arbitraire. Vous avez besoin de fonctions qui peuvent s'endormir, suspendre l'indicateur avec le modificateur - notez explicitement que la fonction peut s'arrêter et attendre que quelque chose soit long. D'une part, vous n'en avez pas besoin dans Loom, car l'exécution peut tout mettre en veille. La solution d'Alibaba est la même: vous pouvez prendre une pile à partir de n'importe quel fil. Ou dans Go - tout peut y être verrouillé, tout code peut s'endormir. Farcir la gorutine et le faire. D'une part, cette approche est très similaire à la programmation avec des threads. C'est comme si vous programmiez comme avant, ce n'est que maintenant que les threads sont appelés fibre et sont devenus très bon marché. Si vous regardez attentivement la présentation du même métier à tisser, il s'avère que les fibres et les fils sont toujours des choses différentes. Comment s’assurer que l’ancien code qui est écrit avec des fils finit complètement hors de la boîte sur les fibres - ce n’est pas évident, et dans quoi ils réussiront - personne ne sait. Les problèmes commencent là: que faire des blocages, que faire du code optimisé pour les sections locales de threads, là encore, certains hachages locaux ou identifiants de threads optimisent les performances. Et Go a le même problème - lorsque les ID matériels ne sont pas exposés, l'écriture d'une sorte d'algorithme haute performance devient non triviale.

Mais à Kotlin, ce n'est pas?

À Kotlin, nous n'essayons pas de prétendre que le fil et la fibre sont la même chose. Nous n'essayons même pas d'exécuter l'ancien code, nous n'avons pas une telle tâche en principe. Nous disons: "Désolé, car nous ne sommes pas à l'exécution, nous ne pouvons pas arbitrairement prendre l'ancien code Java et commencer à changer quelque chose là-bas." Et nous n'essaierons même pas. Nous avons une tâche différente. Nous disons que nous avons une fonctionnalité du langage, des fonctions de sommeil, vous pouvez écrire du code asynchrone avec elles, et ceci est une nouvelle fonctionnalité du langage. Et nous nous éloignons complètement de ce problème ("comment exécuter l'ancien code"), nous disons: "Il y a un nouveau code, bon, orthodoxe, vous pouvez le mettre en veille". Dans une certaine mesure, cela rend la vie plus facile, car vous n'avez pas à planer vous-même ou les gens, mais qu'arrive-t-il si un vieux govnokod qui ne savait pas qu'il le lancerait sur les fibres se lancerait soudainement sur eux.

Dans notre modèle, nous n'avons pas d'ancien code, seulement un nouveau, qui est initialement prêt pour le fait qu'aujourd'hui il est sur un thread, demain sur un autre, et si, par exemple, il a besoin de savoir quel thread est maintenant, il le saura. Oui, vous avez besoin d'un thread local, mais il peut les reconnaître. Cependant, il doit être préparé au fait qu'aujourd'hui les sections locales de threads sont un, et demain - d'autres. S'il veut que ces lieux voyagent avec lui, il existe un autre mécanisme pour cela, un contexte de coroutine où il peut stocker ses affaires, qui, avec coroutine, se déplaceront de fil en fil. Dans un sens, cela nous facilite la vie, car nous n'essayons pas de conserver l'ancien code.

Et d'autre part, nous incitons une personne à penser explicitement à son API, disons: ici j'écris une fonction dans Kotlin avec des coroutines. Si plus tôt je regarde une méthode dans mon code, getWhat ce n'est pas clair, cette méthode fonctionne rapidement et revient immédiatement ou va en ligne et peut fonctionner pendant une heure - je ne peux que lire la documentation et comprendre à quelle vitesse cela fonctionnera. Ou peut-être qu'il travaille vite maintenant, et demain le programmeur Vasya Pupkin viendra et le fera se connecter maintenant. Avec Kotlin Coroutines, nous fournissons un mécanisme garanti par le langage avec un modificateur de suspension . Lorsque je travaille avec des coroutines moi-même, je regarde une fonction, si je ne vois pas le modificateur de suspension, cela signifie qu'il fonctionne rapidement, il fait tout localement. Il y a un modificateur de suspension, ce qui signifie que cette fonction est en quelque sorte asynchrone, elle restera longtemps sur le réseau. Et cela aide à créer une API auto-documentée afin que nous puissions immédiatement voir ce qui nous attend. Cela aide à éviter immédiatement les erreurs stupides quand j'ai oublié quelque part et quelque part dans le code j'ai appelé quelque chose de long sans le soupçonner.

En pratique, c'est très bien. Cela doit marquer explicitement ces fonctions d'endormissement. Dans Go, par exemple, ce n'est pas le cas, je n'ai rien à marquer là-bas. Il s'avère que cet effet secondaire de notre implémentation (qui devrait être marqué avec le modificateur de suspension) vous aide à rendre l'architecture correcte, vous aide à contrôler que vous ne provoquerez pas un jeu asynchrone d'une durée extravagante et aléatoire à l'endroit où vous vous attendiez initialement à ce que tout se passe rapidement.

Mais il y a certaines choses qui sont difficiles à interdire, par exemple, une sorte de fichier d'E / S réseau.

Non, les E / S réseau interdisent simplement assez facilement. Voici le fichier IO - compliqué. Mais là encore, un point délicat: pour la plupart des applications, le fichier IO est une chose rapide, et il est donc parfaitement normal qu'il fonctionne de manière synchrone. Une application très rare fonctionne tellement avec IO que cela devient un problème pour elle de prendre si longtemps. Et ici, nous donnons à une personne la possibilité de choisir: vous pouvez directement créer un fichier IO avec nous et ne pas prendre de bain de vapeur, car cela bloquera ce qui se passe (car il est généralement rapide). Mais si votre cas particulier a juste un calcul très long, il n'est pas asynchrone, mais il consomme juste beaucoup de temps CPU, et vous ne voulez pas bloquer certains de vos autres pools de threads, nous fournissons un mécanisme simple et compréhensible: vous démarrez un mécanisme séparé pool de threads pour son informatique lourde, et au lieu d'écrire une fonction régulière qui est amusante computeSomething () , et d'écrire dans la documentation "Mec, soigneusement, cette fonction peut fonctionner très longtemps, donc attention - ne l'utilisez pas n'importe où, n'utilisez pas UI ", nous proposons une méthode plus simple Khanisme. Vous écrivez simplement cette fonction comme suspendre fun computeSomething () , et pour son implémentation, vous utilisez une fonction de bibliothèque spéciale avec Context , qui jette le calcul dans le pool de threads spécial que vous avez spécifié. C'est très pratique: l'utilisateur n'a plus besoin de faire monter le cerveau: il voit immédiatement une suspension, sait que cet appel ne bloque pas son thread, et il peut assez facilement l'appeler à partir d'un flux d'interface utilisateur et ainsi de suite.

Il passera au flux souhaité déjà à l'intérieur et son flux ne sera pas bloqué. Il s'agit de la séparation correcte des préoccupations: l'utilisateur ne se soucie pas de la façon dont il est implémenté, mais celui qui l'implémente peut correctement transférer vers le pool auquel il est nécessaire et répartir correctement les ressources informatiques dans son application. En pratique, cela s'avère très pratique en termes de style de programmation. Nous devons écrire moins de documentation, le compilateur vérifiera et corrigera davantage.

Je pense à quel point c'est sûr. Quelqu'un peut-il casser un pool de threads ou pénétrer dans les données de quelqu'un d'autre?

Naturellement, tout est possible. Il est difficile de se protéger des mains tordues. Il est clair que peu importe combien nous écrivons toutes sortes de systèmes de type et vérifie dans le compilateur, tout peut toujours être cassé. La question est que le compilateur devrait aider à écrire le code correct. Malheureusement, le rêve d'interdire le mauvais code est utopique. Nous n'incluons spécifiquement aucune fonctionnalité dans la langue. Il n'y a pas de choses Java dans Kotlin si on sait à leur sujet qu'elles sont principalement utilisées à d'autres fins et que le code avec elles est surtout mauvais. Mais toute bonne fonctionnalité qui est dans Kotlin peut être utilisée à d'autres fins dans une multitude de façons différentes. Il n'y a malheureusement pas d'options. La langue peut être utilisée de différentes manières. Vous ne pouvez pas vous protéger des mains tordues.

J'ai appris des étudiants de Kotlin quelle question intéressante vous pouvez poser. Ils ont abandonné et ont dit que vous êtes très rusé et éludez avec souplesse leurs questions.

De quelles questions?

Par exemple, une question a survécu à deux personnes: pourquoi à Kotlin il n'y a pas de types bruts? Pas de génériques.

Parce que vous pouvez toujours écrire un astérisque.

Et sera-t-il compatible avec Java?

Oui

Autrement dit, vous avez une sorte de méthode java qui nécessite quelque chose sans générique. Liste, par exemple.

S'il existe une telle méthode java sans générique, vous pouvez y passer n'importe quelle liste. Vous pouvez transférer List avec un astérisque, vous pouvez avec une chaîne. Kotlin vous permettra de transférer n'importe quel jeu vers la méthode 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, , . , - , . . , , .

, .

Bien sûr. , . 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 — , , - . .

?

Oui , , .

, …

, . , . Loom . - JVM. , .

, , Java?

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

- ?

, … , . . JVM JS.

Node.js?

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

« ». , ?

Bien sûr. , , . 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 . Mais pourquoi? , 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 ?

Bien sûr! , , - CRUD-. : , , — , . -, — , . , TypeScript Flow — JS.

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

, — double…

, . , , .

- .

.

?

Je détiens des olympiades :-) Et je participe moi-même, mais rarement.

Je vois juste qu'aux Jeux olympiques, Java est parfois disponible comme l'une des principales langues.

Maintenant, il est disponible presque toujours. Elle est apparue il y a une quinzaine d'années. Java et C ++ sont deux langages standard qui prennent tous en charge, puis des variantes, selon la concurrence.

Est-il plus difficile de gagner en Java, y a-t-il des frais généraux cachés?

Cela dépend de la compétition. Dans une compétition normale, c'est la même chose s'il y a plus de tâches dans l'idée et l'algorithme correct. Mais il y a une sorte de jeu où les tâches impliquent une optimisation non asymptotique, où vous devez tout optimiser au rythme - là, bien sûr, ce sera difficile en Java, vous devrez essayer beaucoup. De plus, le délai de test est très court. En gros, si vous avez une limite de temps d'exécution de plusieurs secondes, HotSpot se réchauffe sur un petit code en une seconde et ne s'en soucie pas. Et si vous avez une limite à tout - une seconde, alors en Java, vous pouvez simplement perdre en raison du fait que pendant que HotSpot se réchauffe et se compile - une seconde s'est écoulée.

Oui, il y a des compétitions sauvages où Java est difficile. Mais les compétitions normales (populaires, soutenues par de bonnes personnes) - ils essaient de faire les tâches et l'environnement de manière à ce que Java et plus aient des chances égales. Et les raisons sont claires: bien que Java ne se développe pas dans l'éducation, il ne diminue pas beaucoup nulle part. Quelque part, certaines universités ont refusé d'apprendre Java et sont passées à Python - et pour cette raison, notamment, de nombreuses compétitions ont maintenant appris Python. Il s'agit d'une telle troisième langue stable prise en charge. Les concours sont principalement étudiants. Il y a des compétitions professionnelles et les grandes entreprises font quelque chose comme la Facebook Hacker Cup, à laquelle tout le monde peut participer, mais le sujet principal de la programmation sportive est l'école et les étudiants. Pendant les années scolaires et étudiantes, les gens se produiront et s'entraîneront constamment. Mais après l'obtention du diplôme, après avoir travaillé - très peu de gens continueront de participer. Par conséquent, le choix des langues est déterminé par ce qui est utilisé dans l'éducation. S'ils enseignent des avantages, Java et python, ils seront alors aux compétitions. Pour de nombreux programmeurs, Java est la première langue, respectivement, toutes les compétitions tentent de prendre en charge Java. Par souci de compétition pour apprendre le jeu C ++. C'est pour la programmation système, la programmation de bas niveau, vous n'avez pas besoin d'avoir un million de programmeurs C ++, c'est inutile du tout.

Comment aimez-vous l'idée d'ajouter Kotlin à la liste des langues standard?

Eh bien, en fait, nous promouvons activement cette idée. Il y a un ICPC, qui a lieu chaque année, rassemble des centaines de milliers de participants à travers le monde, plus d'une centaine d'équipes se rendent en finale. Dans ICPC, Kotlin est pris en charge. Il existe maintenant une liste de langages: C / C ++, Java, Python et Kotlin. Mais pour l'instant, bien sûr, personne n'y écrit vraiment, à cause de ce problème: la pénétration de l'éducation à un stade très précoce. Dans les compétitions étudiantes, les langues utilisées sont enseignées aux élèves.

Est-ce que Kotlin a déjà été enseigné quelque part?

Quelque part exactement enseigné. Par exemple, à l'École polytechnique de Saint-Pétersbourg. Mais nous en sommes à un stade très précoce, à «l'étape 0» de ce processus.

Il n'y a pas de défauts fatals?

Non, le kotlin est meilleur pour l'enseignement primaire que les autres langues. L'éducation est conservatrice. Les gens ont un programme tout fait, des manuels. Personne n'aime le changement. Pourquoi un professeur qui enseigne la programmation dans sa première année d'étudiants changerait-il sa langue, quel est le bonus? Cela peut être réexaminé tous les dix ans.

Le bonus, par exemple, est que la personne qui le quitte sera plus adaptée à la réalité.

Non. Parce qu'il n'est pas si important de savoir quelle langue vous avez apprise en premier. Un programmeur professionnel de sa vie a étudié une douzaine de langues et utilise activement environ trois langues. De plus, tout cela change constamment. Ce que l'on vous apprendra à programmer en premier n'est pas si important. Il est important de savoir combien de langues vous avez en sortant d'une université - c'est un autre sujet, c'est important. Et ici, nous sommes confrontés à des problèmes sur des marchés conservateurs axés sur l'autorité. Par exemple, en Chine, il y a un problème qui est clarifié après avoir parlé avec les gars de là-bas. Vous prenez n'importe quel grand bureau dans lequel il y a beaucoup de programmeurs, vous demandez - pourquoi vous n'utilisez pas Kotlin? Mais parce que maintenant, les gars n'enseignaient pas le kotlin à l'université, et ils ne veulent rien apprendre de nouveau, mais pourquoi le feraient-ils?

N'est-ce pas ainsi chez nous?

C'est partout, juste à une échelle différente. Dans différentes cultures de différentes manières. Il y a des cultures dans lesquelles, comme l'a dit le gourou, ou comme l'a dit l'enseignant, vous le ferez. Quelque part, les gens sont plus indépendants, plus enclins à l'expérimentation, à l'innovation. Quelque part, les gens iront tout apprendre par eux-mêmes. Quelque part, ils ne lèveront pas le petit doigt et feront exactement ce qui leur a été enseigné. Il y a plus d'implémentations de Kotlin en Russie, mais c'est aussi parce que nous sommes originaires d'ici, nous parlons plus lors de conférences et ainsi de suite.

C'est dans ma génération, les programmeurs ont été des passionnés. J'ai grandi quand ceux qui l'ont aimé ont programmé, ils ont tout étudié par eux-mêmes, car il n'y avait rien. Et maintenant, c'est la chose de masse qui est enseignée. Prenez un programmeur moderne, la plupart ne le font pas parce qu'il aime, mais parce qu'ils lui ont appris cela et maintenant ils paient beaucoup d'argent. En conséquence, ces personnes n'étudieront pas la technologie qui vient d'être lancée. Pourquoi en ont-ils besoin?

Parce que vous gagnerez beaucoup d'argent en utilisant les fonctionnalités intéressantes de cette technologie.

Bien sûr que non! À Kotlin, vous êtes plus susceptible d'obtenir plus de plaisir.

Il y a des choses spécifiques qui ont vraiment une valeur commerciale - nous avons parlé de réutilisation entre l'avant et l'arrière ...

Tout le monde n'en a pas besoin. D'un autre côté, et du plaisir aussi. Tout le monde n'aime pas du tout son travail. Ils sont payés en argent - ils travaillent, cela ne fait aucune différence pour eux qu'ils apprécient ou non. La journée de travail s'est terminée - ils ont fermé et l'ont oublié et ont commencé à faire d'autres choses.

C'est en quelque sorte très ennuyeux, sinon terrible.

C'est la vérité de la vie, malheureusement. Peu importe combien elle est terrible. Et ces personnes, bien sûr, s'en moquent. Kotlin, pas Kotlin.

Pour autant que je comprends, beaucoup de gens travaillent chez JetBrains parce qu'ils aiment travailler.

JetBrains à cet égard est bien sûr un échantillon non représentatif. Des gens spécialement sélectionnés, motivés, qui aiment vraiment cette chose.

Notre temps touche à sa fin, la question est donc: pouvez-vous transmettre quelque chose à nos lecteurs sur Habré? Des mots d'adieu, une révélation?

Je peux transmettre des salutations ardentes :-) Mais je ne dirai aucune révélation, quel genre de révélation peut être? La seule conclusion qui peut être tirée de notre conversation est que celui qui aime le travail est heureux. J'ai lu plusieurs blogs de bonnes personnes qui ont programmé en Java, ont juste travaillé sans plaisir. Et puis pour une raison quelconque, ils sont devenus curieux, la vie les a créés, ils ont essayé Kotlin et ont découvert de façon inattendue que vous pouvez aimer travailler. Que vous pouvez aimer ce que vous faites. Ce que vous pouvez aimer un langage de programmation. Et pas seulement pour l'utiliser, sans émotion, comme un outil. Bien sûr, la langue est un outil, mais vous pouvez vous y rapporter indirectement, ou vous pouvez l'aimer. Il s'agit d'une attitude différente, y compris une attitude différente à l'égard du travail.

Kotlin a beaucoup de gens qui ont des sentiments chaleureux comparables à l'amour, précisément parce que Kotlin est juste agréable à programmer, surtout après Java. Peut-être pas juste après Java. Il n'y a probablement pas de langues dans lesquelles il est si agréable (juste un tel mot) de programmer. Il y a des langues avec plus de fonctionnalités, avec des fonctionnalités plus fortes, il y a des langues avec un système de type plus strict, il y a des langues où tout est pur, il y a où tout est vice versa - dangereux. Prenez n'importe quelle dimension et vous trouverez des langues qui sont meilleures que Kotlin dans cette propriété. Mais Kotlin a un tel équilibre que ce n’est pas un hasard si à StackOverflow, dans le sondage de cette année, il était deuxième dans le top des langues les plus appréciées. Il semble que le premier soit Rust. Mais Rust n'est pas un concurrent pour nous, car Rust est un langage de programmation système. Nous ne montons pas dans ce créneau. Il n'est pas du tout ennuyeux que Rust à cet égard ait dépassé Kotlin. Nous nous efforçons de faire de Kotlin le langage principal pour la programmation d'applications dans lequel il est agréable de résoudre les problèmes d'application. Nous n'avons pas et n'aurons jamais certaines fonctionnalités de Rust, car elles ne sont tout simplement pas nécessaires au programmeur d'application. Il ne doit pas gérer manuellement la mémoire ou penser aux subtilités de la propriété, un programmeur d'application doit résoudre des problèmes commerciaux. Il doit transformer son domaine en code. Et cela devrait être la transformation la plus directe sans qu'aucun facteur ne s'y oppose. Nous essayons d'éliminer ces facteurs perturbateurs. Pour transformer votre tâche métier le plus directement possible, sans eau ni code supplémentaire, en une solution.

Eh bien, c'est une concurrence quelque peu déloyale - tous ces langages comme Java ont été inventés il y a de nombreuses années, et vous venez de le faire.

Naturellement, Kotlin prend en compte l'expérience de ses prédécesseurs. Comme toute langue moderne. C'est un progrès - quand quelque chose de nouveau est créé en tenant compte des anciennes lacunes. Pour une bonne raison, les types nullables sont fabriqués dans Kotlin. Eh bien, allez loin, prenez n'importe quelle entreprise, rendez-vous dans n'importe quel grand bureau, consultez leurs journaux de plantage, et vous verrez que l'exception la plus fréquente est NullPointerException. C'est un fait bien connu et si vous créez une nouvelle langue, vous devez la résoudre. Par conséquent, nous accordons beaucoup d'attention dans le langage à la nullité. Et ainsi de suite. Si vous ne concevez pas la langue de manière abstraite, non pas comme un exercice académique, mais essayez de résoudre les problèmes des personnes qu'ils rencontrent souvent, alors la langue s'avère bonne. Pourquoi est-il aimé? Parce qu'il résout leurs problèmes.