Wenn Sie etwas herausfinden möchten, lernen Sie direkt von den Besten. Heute werden meine Fragen vom Gott Corutin und der Parallelität Roma elizarov Elizarov beantwortet. Wir haben nicht nur über Kotlin gesprochen, wie Sie vielleicht denken, sondern auch über eine Reihe verwandter Themen:

• Golang und Goroutinen;
• JavaScript und seine Anwendbarkeit für ernsthafte Projekte;
• Java und Project Loom;
• Olympiadenprogrammierung auf Kotlin;
• wie man das Programmieren richtig lernt;
• und andere aufregende Dinge.

Kotlin - gut gemacht!

Hallo. Zuerst ein paar Worte über dich. Machst du schon lange Kotlin?

Ich habe eine lange Geschichte mit Kotlin. 2010 begann Kotlin als Projekt bei JetBrains, wo ich zu diesem Zeitpunkt nicht arbeitete. Aber Max Shafirov (er war damals mit Kotlin beschäftigt und einer der Initiatoren dieser Bewegung innerhalb von JetBrains) lud mich ein, ein externer Experte zu werden und mir das Design und den Kommentar anzusehen. Ursprünglich wurde die Sprache entwickelt, um ihre Probleme zu lösen, da JetBrains über eine eigene große Basis an Java-Code mit verständlichen Problemen verfügt, die ständig im Code vorhanden sind, und ich wollte die Sprache für mich selbst erstellen, damit mein Code angenehmer, effizienter und mit weniger Fehlern geschrieben werden kann. Führen Sie einfach eine Modernisierung durch. Dies führte natürlich schnell zu der Idee, dass, da wir solche Probleme haben, dies bedeutet, dass andere solche Probleme haben und sie die Bestätigung anderer Menschen benötigen, dass sie den richtigen Weg gehen.

Ich wurde als Experte eingeladen, um zu sehen und zu vergleichen, was passiert und was benötigt wird. Über die Nullbarkeit - Ich bestand darauf, dass dies getan werden sollte, da mir in diesem Moment klar war, dass es beim Schreiben in Java viele Probleme gibt, aber die Nullfähigkeit ist das Hauptproblem, auf das Sie ständig stoßen.

Ich habe nicht an der Arbeit des Teams teilgenommen, ich habe nur regelmäßig einen Blick darauf geworfen und an Wettbewerben beim Kotlin (Kotlin Cup) teilgenommen. Ich habe mein ganzes Leben lang an Wettkämpfen teilgenommen, aber selbst dann habe ich nicht aktiv teilgenommen. Zum Beispiel hätte ich das Finale von Wettbewerben wie dem Facebook Hacker Cup nicht erreicht, die Form ist nicht dieselbe, weil ich nicht mehr an Wettbewerben teilnehme. Und ich nahm am Kotlin Cup teil und erreichte leicht das Finale, da es kein breites Publikum anzog.

Zu dieser Zeit (2012-2013) war Kotlin aus Sicht der Abstimmung ein trauriger Anblick, weil sich dort alles verlangsamte. Seitdem hat das Team großartige Arbeit geleistet. Ich bin dem Team vor zwei Jahren beigetreten, direkt nach der Veröffentlichung von 1.0 und bevor Google die Sprache offiziell erkannt hat. Als Team habe ich alle Arten von Asynchronität und Coroutinen aufgegriffen. Nur weil sich herausstellte, dass ich die richtige Erfahrung hatte, habe ich viel in verschiedenen großen Unternehmenssystemen bei DevExperts gearbeitet und es gibt viel Asynchronität und Kommunikation. Daher habe ich mir die Problembereiche gut vorgestellt - was muss behoben werden und was tut den Menschen weh. Dies fiel sehr gut auf die Bedürfnisse von Kotlin, weil es nicht nur bei uns weh tut. Es tut allen weh. Sogar die JVM hat Project Loom gestartet, was sozusagen darauf hindeutet, dass es allen weh tut. Ich beschäftige mich immer noch mit Kotlin-Bibliotheken, und unser Hauptaugenmerk liegt auf allen Arten von verbundenen Anwendungen und Asynchronität.

Das heißt, Sie beschäftigen sich hauptsächlich mit Bibliotheken, nicht mit einem Compiler, und das ist alles dafür?

Nein, ich mache den Compiler, soweit. Ich kommuniziere mit den Jungs und unser Bibliotheksteam bereitet alles vor, was sie im Compiler tun. Wir sind auch Kunden, wir erstellen viele Feature-Quests, wenn wir auf einige Mängel stoßen, und wir sind Tester der ersten Zeile von allem, was neu ist.

Es stellt sich heraus, wenn Sie in YouTrack gehen und nach Ihnen filtern, können Sie viele interessante Dinge finden.

Ja, Sie können eine Reihe von Aufgaben aller Art finden, weil ich ständig auf etwas stoße.

Sie haben Project Loom erwähnt. Es wurde von dem Typ gemacht, der Quasar gemacht hat. Von der Seite sieht es sehr lustig aus, ich wollte nur einen Artikel über Habra über Loom schreiben. Kannst du mir etwas über ihn erzählen?

Ich habe eine Präsentation gesehen, die Idee ist klar. Jeder braucht Coroutinen und asynchrone Programmierung. Zum Beispiel haben die Jungs von Alibaba in der Vergangenheit bei JPoint erzählt, wie sie die JVM gehackt und den Hotspot vermasselt haben. Sie haben nur einen Patch eingefügt, den sie nicht einmal geschrieben haben, aber einige Jungs vor ihnen. Sie sägten später unter sich. Toller Bericht. Ich kann es nur empfehlen.

Empfehlen Sie dies?

So ist es notwendig , in Unternehmen zu tun. Jedes große Unternehmen über einer bestimmten Größe, wenn mehrere tausend Personen für Sie (und für weniger Personen) arbeiten, behält Ihren OpenJDK-Hack bei. Und wenn Sie geschäftskritische Benutzerfälle haben, warum dann nicht etwas für sich selbst hacken, sehe ich darin kein großes Problem. Nicht dass ich es empfehlen würde, aber ich muss. Was soll ich tun, wenn HotSpot keine einfachen Threads enthält? Dies legt in der Tat nahe, dass die Menschen das brauchen, was reif ist. Und das Feedback, das wir zu Coroutinen erhalten, besagt auch, dass es überfällig ist, Menschen brauchen leichte Streams, Menschen brauchen einen Wagen mit Yuzkeys für leichte Streams. Die Tatsache, dass sie irgendwie im JDK unterstützt werden sollten, ist längst überfällig, und in diesem Sinne habe ich keinen Zweifel daran, dass Loom früher oder später in Produktion gehen wird, wenn es gefragt ist. Es gibt Leute, die es brauchen. Es gibt Leute, die sogar für diesen Patch HotSpot.

Ich habe ein häufiges Problem gesehen - Sie haben eine Art Webserver, viele Leute klopfen daran und es beginnt, Threads zu blockieren.

Dies ist ein ziemlich häufiges Problem. Und der Webserver, der Anwendungsserver und das Backend. Wenn Sie sich dieselbe Präsentation von Alibaba ansehen, warum dieses Ding benötigt wurde, dann haben sie keinen Webserver, sie haben eine klassische Unternehmensarchitektur, sie haben alle Arten von Diensten, die im Java-Backend geschrieben sind, diese Dienste sind unter Last. Ich habe auf die gleiche Weise mit DevExperts gearbeitet: Dienste sind unter Last, Sie erhalten Anfragen, die Sie schließlich nicht bearbeiten - in der modernen Welt haben Sie alles miteinander verbunden. Und Sie bearbeiten diese Anfrage nicht selbst, sondern rufen alle anderen Dienste unter 100500 an und warten, bis sie antworten. Und wenn diese Dienste langsam sind, warten viele Threads. Sie können es sich nicht leisten, Zehntausende dieser wartenden Streams zu haben. Und nur wegen eines Unsinns erhalten Sie Folgendes: Ein Dienst, den Sie verwenden, verlangsamt sich, und viele Threads stehen und warten. Und jetzt ist das ein sehr großes Problem.

Einer der Gründe, warum Menschen massiv nach Go migrieren, ist nicht, dass die Sprache gut ist, sondern dass es leichte Abläufe gibt und es kein solches Problem gibt: Goroutinen können warten und kosten nichts. In derselben Alibaba ist die von ihnen implementierte Lösung im Allgemeinen dumm von allen dummen. Sie sind nicht sehr leicht in dem Sinne, dass sie jeder Coroutine einen großen Stapel von 2 Megabyte zuweisen und HotSpot hacken, damit diese Stapel gewechselt werden können. Sie sparen den physischen Fluss, aber keine Stapel. Und für sie funktioniert die Lösung - übrigens ist es sehr einfach, sie haben einen HotSpot-Patch, wie ich es verstehe, nicht sehr groß. Die Jungs von Loom haben etwas globaleres angefangen. Sie beschlossen, nicht nur auf physischen Streams, sondern auch auf dem Stack zu speichern, um nicht 2 Megabyte pro Stream auszugeben. Im Prototyp durchläuft der aktuelle Stack HotSpot und wird in eine kleine Hüftstruktur kopiert. Und sie können diesen physischen Stapel für andere Zwecke wiederverwenden.

Aber es gibt so einen listigen Hack: Wenn Sie zur Leistung zurückkehren, kopieren sie nicht alles, sondern nur die Spitze.

Ja, es gibt Autos mit Hacks und Optimierungen. Was letztendlich daraus entsteht, ist sehr schwer zu sagen. Denn am Beispiel des Kopieransatzes tritt sofort das folgende Problem auf: Was tun mit nativen Aufrufen? Innerhalb des nativen Aufrufs können Sie den Stapel des nativen Aufrufs nicht mehr kopieren. Alibabas Ansatz hat kein solches Problem. Native, nicht native - was ist der Unterschied, Sie haben diesen Stapel einfach ganz ausgehängt und in Ruhe gelassen, einen anderen Stapel aufgenommen, alles funktioniert. Und es ist zu früh zu sagen, ob es gelingen wird oder nicht, manchmal können Sie mit diesem nativen Stapel leben, manchmal können Sie nicht - zu diesem Zeitpunkt ist es zu früh, um zu sagen. Zum Beispiel ist die Implementierung in Go ein völlig anderer Mechanismus. Während Sie Gosh-Code ausführen, werden kleine Gosh-Stapel verwendet. Wenn eine Gosh-Laufzeit eine Funktion aufruft, wird dementsprechend geprüft, wie viel der Stack benötigt. Wenn der aktuelle Stapel nicht ausreicht, wird er neu zugewiesen - vergrößert den ausgewählten Stapel. Wenn Sie dementsprechend einen nativen Aufruf tätigen, nehmen sie bereits einen großen nativen Stapel aus einem bestimmten Pool und verwenden ihn.

Und für Gosh Code auch?

Nicht wichtig. Sie können einfach zu einem großen nativen Stapel wechseln, wenn Sie eine externe Funktion aufrufen müssen, für die nicht klar ist, wie viel ein Stapel benötigt wird. Und wenn Sie den Gosh-Code ausführen, wissen Sie, wie viele Stapel benötigt werden, damit wir ihn auf einem kleinen Stapel ausführen können. Dies ist ein völlig anderer Ansatz. Nicht kopieren, sondern sofort auf einem kleinen Stapel ausführen. Tatsächlich gibt es keinen großen Unterschied zwischen diesen Ansätzen, bis Sie gelegentlich einschlafen.

Wir werden ständig gefragt: „Was ist schneller? Was ist geeignet? Wie macht man das in Coroutinen? “ Wir in Coroutinen hacken die JVM nicht. Unser Ziel ist es, dass dies unter der normalen JVM funktioniert. Und damit Android auch funktioniert. Es gibt eine eigene KUNST, die auch nichts über Coroutinen weiß. Und so müssen wir natürlich Bytes mit Stiften generieren, was dem Kopieren des Stapels, den Loom macht, sehr ähnlich ist, nur dass wir es in Bytecode machen. Wir nehmen es, wenn es schon spät ist. Nehmen Sie einen Stapel, entspannen Sie sich und kopieren Sie ihn in die Hüfte. Wir haben keine Laufzeit, die dies für uns tun würde, wir haben einen Bytecode generiert, der dies tut. Es bewahrt und stellt den Zustand der Coroutine wieder her. Aufgrund der Tatsache, dass wir keine Laufzeit haben, haben wir natürlich mehr Overhead. Zur Laufzeit können Sie alles schneller erledigen. Wenn Sie dagegen Coroutinen für die asynchrone Programmierung verwenden, müssen Sie einschlafen, wenn Sie auf eine Antwort eines Dienstes warten und eine Anfrage an einen Dienst senden müssen, ist dies so teuer, dass der gesamte Aufwand beim Kopieren des Stapels niemanden stört. ob es langsam oder schnell ist, spielt überhaupt keine Rolle. Ja, wenn Sie es speziell für die asynchrone Programmierung verwenden. Auf Coroutinen in Kotlin skaliert es bemerkenswert, wie im Prototyp Project Loom gezeigt.

Ein weiterer Unterschied ist, dass wir in Kotlin gezwungen sind, dies im Bytecode zu tun, was einen so interessanten Nebeneffekt hat. Einerseits scheint es erfolglos zu sein, andererseits im Gegenteil. Es besteht aus Folgendem: Es ist unmöglich, eine beliebige Funktion einzuschläfern. Sie benötigen Funktionen, die einschlafen können, markieren Sie Suspend mit dem Modifikator. Beachten Sie ausdrücklich, dass die Funktion möglicherweise pausiert und darauf wartet, dass etwas lang ist. Einerseits benötigen Sie dies in Loom nicht, da die Laufzeit alles in den Ruhezustand versetzen kann. Die Lösung von Alibaba ist dieselbe: Sie können einen Stapel von jedem Thread nehmen. Oder in Go - dort kann alles eingesperrt werden, jeder Code kann einschlafen. Füllen Sie Gorutin und machen Sie es. Einerseits ist dieser Ansatz der Programmierung mit Threads sehr ähnlich. Es ist, als ob Sie wie zuvor programmieren. Erst jetzt werden die Threads als Glasfaser bezeichnet und sind sehr billig geworden. Wenn Sie sich die Präsentation desselben Webstuhls genau ansehen, stellt sich heraus, dass Fasern und Fäden immer noch unterschiedliche Dinge sind. Wie man sicherstellt, dass der alte Code, der mit Threads geschrieben wurde, vollständig aus der Box auf den Fasern aufgewickelt wurde - es ist nicht offensichtlich und was ihnen gelingen wird -, weiß niemand. Dort beginnen Probleme: Was tun mit Deadlocks, was tun mit Code, der für Thread-Lokale optimiert ist? Wiederum führen einige lokale Hashes oder Thread-IDs einige Leistungsoptimierungen durch. Und Go hat das gleiche Problem: Wenn Hardware-IDs nicht verfügbar sind, ist das Schreiben eines Hochleistungsalgorithmus nicht trivial.

Aber in Kotlin ist das nicht?

In Kotlin versuchen wir nicht vorzutäuschen, dass Faden und Faser dasselbe sind. Wir versuchen nicht einmal, den alten Code auszuführen, wir haben im Prinzip keine solche Aufgabe. Wir sagen: "Entschuldigung, da wir keine Laufzeit haben, können wir den alten Java-Code nicht willkürlich nehmen und dort etwas wechseln." Und wir werden es nicht einmal versuchen. Wir haben eine andere Aufgabe. Wir sagen, dass wir eine Funktion der Sprache haben, Einschlaffunktionen, Sie können asynchronen Code mit ihnen schreiben, und dies ist eine neue Funktion der Sprache. Und wir distanzieren uns völlig von diesem Problem („wie man den alten Code ausführt“), wir sagen: „Es gibt einen neuen Code, gut, orthodox, Sie können ihn einschläfern lassen.“ Bis zu einem gewissen Grad erleichtert dies das Leben, da Sie weder sich selbst noch die Menschen in die Höhe treiben müssen. Was passiert jedoch, wenn ein alter Govnokod, der nicht wusste, dass er es auf die Fasern abfeuern würde, plötzlich auf sie abfeuern würde?

In unserem Modell haben wir keinen alten Code, nur einen neuen, der zunächst bereit ist für die Tatsache, dass er sich heute in einem Thread befindet, morgen in einem anderen, und wenn er beispielsweise herausfinden muss, welcher Thread jetzt ist, wird er ihn kennen. Ja, Sie benötigen einen lokalen Thread, aber er kann sie erkennen. Er muss jedoch darauf vorbereitet sein, dass heute Thread-Einheimische eins sind und morgen andere. Wenn er möchte, dass diese Orte mit ihm reisen, gibt es dafür einen anderen Mechanismus, einen Coroutine-Kontext, in dem er seine Sachen aufbewahren kann, die zusammen mit Coroutine von Thread zu Thread wandern. Dies erleichtert uns in gewisser Weise das Leben, da wir nicht versuchen, den alten Code beizubehalten.

Auf der anderen Seite lassen wir eine Person explizit über ihre API nachdenken, sagen wir: Hier schreibe ich eine Funktion in Kotlin mit Coroutinen. Wenn ich mir früher eine Methode in meinem Code anschaue , getWhat es nicht klar ist, funktioniert diese Methode schnell und kehrt sofort zurück oder geht online und kann eine Stunde lang funktionieren - ich kann nur die Dokumentation lesen und verstehen, wie schnell sie funktionieren wird. Oder vielleicht arbeitet er jetzt schnell und morgen wird der Programmierer Vasya Pupkin kommen und ihn jetzt online gehen lassen. Mit Kotlin Coroutines bieten wir einen sprachgarantierten Mechanismus mit einem Suspend- Modifikator. Wenn ich selbst mit Coroutinen arbeite, sehe ich mir eine Funktion an. Wenn ich den Suspend-Modifikator nicht sehe, bedeutet dies, dass er schnell funktioniert und alles lokal erledigt. Es gibt einen Suspend-Modifikator, was bedeutet, dass diese Funktion irgendwie asynchron ist und lange im Netzwerk bleibt. Und es hilft, eine selbstdokumentierende API zu erstellen, damit wir sofort sehen können, was uns erwartet. Dies hilft, dumme Fehler sofort zu vermeiden, wenn ich irgendwo im Code etwas vergessen habe, das ich lange aufgerufen habe, ohne es zu ahnen.

In der Praxis ist das sehr gut. Dies muss diese Einschlaffunktionen explizit markieren. In Go zum Beispiel ist dies nicht der Fall, ich muss da draußen nichts markieren. Es stellt sich heraus, dass dieser Nebeneffekt unserer Implementierung (der mit dem Modifikator suspend gekennzeichnet werden sollte) Ihnen hilft, die Architektur richtig zu machen und zu kontrollieren, dass Sie kein zufälliges, wild langes asynchrones Spiel an der Stelle verursachen, an der Sie ursprünglich erwartet hatten, dass alles schnell gehen würde.

Es gibt jedoch einige Dinge, die schwer zu verbieten sind, z. B. eine Art Netzwerk-E / A-Datei.

Nein, Netzwerk-E / A verbieten es ganz einfach. Hier ist die Datei IO - kompliziert. Aber auch hier ein heikler Punkt: Für die meisten Anwendungen ist Datei-E / A eine schnelle Sache, und daher ist es völlig normal, dass sie synchron funktioniert. Eine sehr seltene Anwendung funktioniert so oft mit E / A, dass es zu einem Problem wird, wenn sie so lange dauert. Und hier geben wir einer Person die Möglichkeit zu wählen: Sie können direkt eine E / A-Datei mit uns erstellen und kein Dampfbad nehmen, da dies das Geschehen blockiert (weil es normalerweise schnell ist). Wenn Ihr spezieller Fall jedoch nur eine sehr lange Berechnung hat, ist er nicht asynchron, sondern verbraucht nur viel CPU-Zeit und Sie möchten einige Ihrer anderen Thread-Pools nicht blockieren. Wir bieten einen einfachen verständlichen Mechanismus: Sie starten einen separaten Thread-Pool für seine schwere Rechenleistung, und anstatt eine reguläre Funktion zu schreiben, die Spaß macht, computeSomething () , und in die Dokumentation zu schreiben: „Leute, sorgfältig, diese Funktion kann sehr lange funktionieren, also Aufmerksamkeit - verwenden Sie sie nirgendwo, verwenden Sie sie nicht UI “bieten wir eine einfachere Methode an Khanismus. Sie schreiben diese Funktion einfach als suspend fun computeSomething () und verwenden für ihre Implementierung eine spezielle Bibliotheksfunktion withContext , die die Berechnung in den von Ihnen angegebenen speziellen Thread-Pool wirft. Dies ist sehr praktisch: Der Benutzer muss das Gehirn nicht mehr hochfliegen lassen: Er sieht sofort eine Unterbrechung, weiß, dass dieser Aufruf seinen Thread nicht blockiert, und er kann ihn ganz einfach über einen UI-Stream usw. aufrufen.

Es wechselt zu dem gewünschten Stream, der sich bereits im Inneren befindet, und sein Stream wird nicht blockiert. Dies ist die richtige Trennung von Bedenken: Dem Benutzer ist es egal, wie es implementiert wird, aber derjenige, der es implementiert, kann es korrekt in den Pool übertragen, in dem es benötigt wird, und die Rechenressourcen in seiner Anwendung korrekt verteilen. In der Praxis erweist sich dies hinsichtlich des Programmierstils als sehr praktisch. Wir müssen weniger Dokumentation schreiben, der Compiler wird mehr prüfen und korrigieren.

Ich denke wie sicher es ist. Kann jemand einen Thread-Pool aufbrechen oder in die Daten eines anderen einbrechen?

Natürlich ist alles möglich. Es ist schwer, sich vor krummen Händen zu schützen. Es ist klar, dass unabhängig davon, wie viel wir alle Arten von Typsystemen schreiben und im Compiler prüfen, immer alles kaputt gehen kann. Die Frage ist, dass der Compiler beim Schreiben des richtigen Codes helfen soll. Leider ist der Traum, schlechten Code zu verbieten, utopisch. Wir nehmen ausdrücklich keine Funktionen in die Sprache auf. Es gibt keine Java-Dinge in Kotlin, wenn bekannt ist, dass sie hauptsächlich für andere Zwecke verwendet werden und der Code mit ihnen meistens schlecht ist. Aber jede gute Funktion in Kotlin kann auf vielfältige Weise für andere Zwecke verwendet werden. Leider gibt es keine Optionen. Sprache kann auf viele verschiedene Arten missbraucht werden. Sie können sich nicht vor krummen Händen schützen.

Ich habe von Kotlin-Schülern gelernt, was für eine interessante Frage Sie stellen können. Sie gaben auf und sagten, dass Sie sehr gerissen sind und ihren Fragen flexibel ausweichen.

Aus welchen Fragen?

Zum Beispiel überlebte eine Frage zwei Menschen: Warum gibt es in Kotlin keine rohen Typen? Keine Generika.

Weil Sie immer ein Sternchen schreiben können.

Und wird es mit Java kompatibel sein?

Ja

Das heißt, Sie haben eine Art Java-Methode, die etwas ohne Generika erfordert. Liste zum Beispiel.

Wenn es eine solche Java-Methode ohne Generikum gibt, können Sie dort eine beliebige Liste übergeben. Sie können List mit einem Sternchen übertragen, Sie können mit einer Zeichenfolge. Mit Kotlin können Sie jedes Spiel auf die Java-Methode übertragen. 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, , . , - , . . , , .

, .

Natürlich. , . 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 — , , - . .

?

Ja , , .

, …

, . , . Loom . - JVM. , .

, , Java?

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

- ?

, … , . . JVM JS.

Node.js?

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

« ». , ?

Natürlich. , , . 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 . Aber warum? , 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 ?

Natürlich! , , - CRUD-. : , , — , . -, — , . , TypeScript Flow — JS.

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

, — double…

, . , , .

- .

.

?

Ich halte Olympiaden :-) Und ich selbst nehme teil, aber selten.

Ich sehe nur, dass Java bei den Olympischen Spielen manchmal als eine der Hauptsprachen verfügbar ist.

Jetzt ist es fast immer verfügbar. Sie erschien vor ungefähr fünfzehn Jahren. Java und C ++ sind zwei Standardsprachen, die alle unterstützen, und je nach Konkurrenz Variationen.

Ist es schwieriger in Java zu gewinnen, gibt es versteckte Gemeinkosten?

Das hängt von der Konkurrenz ab. In einem normalen Wettbewerb ist es dasselbe, wenn die Idee und der richtige Algorithmus mehr Aufgaben enthalten. Aber es gibt eine Art Spiel, bei dem Aufgaben eine nicht asymptotische Optimierung beinhalten, bei der Sie alles im Takt optimieren müssen - dort wird es in Java natürlich schwierig, Sie müssen viel versuchen. Außerdem gibt es eine sehr kurze Testvorlaufzeit. Grob gesagt, wenn Sie ein Laufzeitlimit von mehreren Sekunden haben, erwärmt sich HotSpot in einer Sekunde auf einen kleinen Code und es ist ihm egal. Und wenn Sie ein Limit für alles haben - eine Sekunde, dann können Sie in Java einfach verlieren, weil beim Aufwärmen und Kompilieren von HotSpot eine Sekunde vergangen ist.

Ja, es gibt wilde Wettbewerbe, bei denen Java schwierig ist. Aber normale Wettbewerbe (beliebt, unterstützt von guten Leuten) - sie versuchen, die Aufgaben und die Umgebung so zu erledigen, dass Java und Plus die gleichen Chancen haben. Und die Gründe liegen auf der Hand: Obwohl Java in der Bildung nicht wächst, nimmt es nirgendwo stark ab. Irgendwo weigerten sich einige Universitäten, Java zu lernen, und wechselten zu Python - und aus diesem Grund haben inzwischen auch viele Wettbewerbe Python gelernt. Dies wird von einer so stabilen dritten Sprache unterstützt. Wettbewerbe sind hauptsächlich Studenten. Es gibt professionelle Wettbewerbe und große Unternehmen veranstalten so etwas wie den Facebook Hacker Cup, an dem jeder teilnehmen kann. Dennoch ist das Hauptthema in der Sportprogrammierung Schule und Schüler. In den Schul- und Schülerjahren werden die Menschen ständig auftreten und trainieren. Aber nach dem Abschluss, nach der Arbeit werden nur noch sehr wenige Menschen teilnehmen. Daher wird die Wahl der Sprachen durch die Verwendung in der Bildung bestimmt. Wenn sie Pluspunkte, Java und Python unterrichten, werden sie an den Wettbewerben teilnehmen. Für viele Programmierer ist Java die erste Sprache. Alle Wettbewerbe versuchen, Java zu unterstützen. Um des Wettbewerbs willen C ++ - Spiel zu lernen. Es ist für die Systemprogrammierung und Low-Level-Programmierung gedacht. Sie benötigen keine Million C ++ - Programmierer. Es ist überhaupt sinnlos.

Wie gefällt Ihnen die Idee, Kotlin zur Liste der Standardsprachen hinzuzufügen?

Nun, eigentlich fördern wir diese Idee aktiv. Es gibt eine ICPC, die jährlich stattfindet, Hunderttausende von Teilnehmern auf der ganzen Welt versammelt, mehr als hundert Teams erreichen das Finale. In ICPC wird Kotlin unterstützt. Jetzt gibt es eine Liste von Sprachen: C / C ++, Java, Python und Kotlin. Aber im Moment schreibt natürlich niemand wirklich darüber, wegen dieses Problems: Eindringen in die Bildung in einem sehr frühen Stadium. In Schülerwettbewerben werden die Sprachen verwendet, in denen die Schüler unterrichtet werden.

Wird Kotlin schon irgendwo unterrichtet?

Irgendwo genau gelehrt. Zum Beispiel in der St. Petersburg Polytechnic. Wir befinden uns jedoch in einem sehr frühen Stadium, am „Schritt 0“ dieses Prozesses.

Es gibt keine schwerwiegenden Mängel?

Nein, Kotlin ist besser für die Grundschulbildung als andere Sprachen. Nur Bildung ist konservativ. Die Leute haben ein fertiges Programm, Lehrbücher. Niemand mag Veränderung. Warum sollte ein Professor, der in seinem ersten Studienjahr Programmieren unterrichtet, seine Sprache ändern? Was ist der Bonus? Dies kann alle zehn Jahre überprüft werden.

Der Bonus ist zum Beispiel, dass die Person, die es verlässt, besser an die Realität angepasst wird.

Nein. Weil es nicht so wichtig ist, welche Sprache Sie zuerst gelernt haben. Ein professioneller Programmierer in seinem Leben hat ein Dutzend Sprachen studiert und verwendet ungefähr drei Sprachen aktiv. Außerdem ändert sich dies ständig. Was Ihnen zuerst das Programmieren beigebracht wird, ist nicht so wichtig. Es ist wichtig, wie viel Sprache Sie beim Abschluss einer Universität haben - dies ist ein weiteres Thema, dies ist wichtig. Und hier stehen wir vor Problemen in konservativen Märkten, die auf Autorität ausgerichtet sind. Zum Beispiel gibt es in China ein Problem, das nach einem Gespräch mit den Jungs von dort geklärt wird. Sie nehmen ein großes Büro, in dem es viele Programmierer gibt, fragen Sie - warum verwenden Sie Kotlin nicht? Aber weil die Jungs jetzt Kotlin nicht an der Universität unterrichtet haben und nichts Neues lernen wollen, aber warum sollten sie?

Ist es nicht so bei uns?

Dies ist überall, nur in einem anderen Maßstab. In verschiedenen Kulturen auf unterschiedliche Weise. Es gibt Kulturen, in denen Sie, wie der Guru oder der Lehrer sagte, dies tun werden. Irgendwo sind die Menschen unabhängiger, experimentierfreudiger und innovativer. Irgendwo werden die Leute alles selbst lernen. Irgendwo werden sie keinen Finger rühren und genau das tun, was ihnen beigebracht wurde. Es gibt mehr Kotlin-Implementierungen in Russland, aber das liegt auch daran, dass wir ursprünglich von hier sind, mehr auf Konferenzen sprechen und so weiter.

Dies ist in meiner Generation, Programmierer waren Enthusiasten. Ich bin aufgewachsen, als diejenigen, die es gern programmiert hatten, alles selbst studierten, weil es nichts gab. Und jetzt ist dies die Massensache, die gelehrt wird. Nehmen Sie einen modernen Programmierer, die meisten tun dies nicht, weil er liebt, sondern weil sie ihm das beigebracht haben und jetzt viel Geld bezahlen. Dementsprechend werden solche Leute die gerade veröffentlichte Technologie nicht studieren. Warum brauchen sie es?

Weil Sie mit den coolen Funktionen dieser Technologie viel Geld verdienen.

Nein, natürlich! In Kotlin werden Sie mit größerer Wahrscheinlichkeit mehr Freude haben.

Es gibt bestimmte Dinge, die wirklich geschäftlichen Wert haben - wir haben über die Wiederverwendung zwischen Vorder- und Rückseite gesprochen ...

Nicht jeder braucht es. Auf der anderen Seite und auch das Vergnügen. Nicht jeder genießt seine Arbeit überhaupt. Sie erhalten Geld - sie arbeiten, es macht für sie keinen Unterschied, ob sie Spaß haben oder nicht. Der Arbeitstag endete - sie schlossen und vergaßen es und begannen andere Dinge zu tun.

Das ist irgendwie sehr langweilig, wenn nicht schrecklich.

Das ist leider die Wahrheit des Lebens. Egal wie schrecklich sie ist. Und solche Leute kümmern sich natürlich nicht darum. Kotlin, nicht Kotlin.

Soweit ich weiß, arbeiten nur viele Leute bei JetBrains, weil sie gerne arbeiten.

JetBrains ist in dieser Hinsicht natürlich eine nicht repräsentative Stichprobe. Speziell ausgewählte Leute, motiviert, die dieses Ding wirklich mögen.

Unsere Zeit neigt sich langsam dem Ende zu, daher lautet die Frage: Können Sie unseren Lesern auf Habré etwas weitergeben? Irgendwelche Abschiedswörter, eine Offenbarung?

Ich kann feurige Grüße übermitteln :-) Aber ich werde keine Offenbarung sagen, was für eine Offenbarung kann das sein? Die einzige Schlussfolgerung, die aus unserem Gespräch gezogen werden kann, ist, dass jeder, der gerne arbeitet, glücklich ist. Ich habe mehrere Blogs von guten Leuten gelesen, die in Java programmiert haben und einfach ohne Vergnügen gearbeitet haben. Und dann wurden sie aus irgendeinem Grund neugierig, das Leben machte sie, sie versuchten es mit Kotlin und entdeckten unerwartet für sich, dass man gerne arbeiten kann. Dass du lieben kannst, was du tust. Was Sie eine Programmiersprache lieben können. Und nicht nur ohne Emotionen als Werkzeug zu verwenden. Natürlich ist Sprache ein Werkzeug, aber Sie können sich indirekt darauf beziehen oder Sie können es lieben. Dies ist eine andere Einstellung, einschließlich einer anderen Einstellung zur Arbeit.

Kotlin hat viele Leute, die ein warmes Gefühl haben, das mit Liebe vergleichbar ist, gerade weil Kotlin einfach gut zu programmieren ist, besonders nach Java. Vielleicht nicht nur nach Java. Es gibt wahrscheinlich keine Sprachen, in denen es so schön ist (nur so ein Wort) zu programmieren. Es gibt Sprachen mit mehr Funktionalität, mit stärkeren Merkmalen, es gibt Sprachen mit einem strengeren Typensystem, es gibt Sprachen, in denen alles rein ist, es gibt Sprachen, in denen alles umgekehrt ist - unsicher. Nehmen Sie eine beliebige Dimension und Sie werden in dieser Eigenschaft Sprachen finden, die besser als Kotlin sind. Kotlin ist jedoch so ausgeglichen, dass es kein Zufall ist, dass er bei StackOverflow in der diesjährigen Umfrage den zweiten Platz in der Liste der beliebtesten Sprachen belegt hat. Der erste war anscheinend Rust. Aber Rust ist für uns kein Konkurrent, weil Rust eine Systemprogrammiersprache ist. Wir klettern nicht in diese Nische. Es ist überhaupt nicht ärgerlich, dass Rust diesbezüglich Kotlin überholte. Wir bemühen uns, Kotlin zur Hauptsprache für die Anwendungsprogrammierung zu machen, in der es angenehm ist, Anwendungsprobleme zu lösen. Wir haben und werden einige Funktionen von Rust nicht haben, da sie vom Anwendungsprogrammierer einfach nicht benötigt werden. Er sollte den Speicher nicht manuell verwalten oder über die Feinheiten des Eigentums nachdenken. Ein Anwendungsprogrammierer muss geschäftliche Probleme lösen. Er muss seine Domain in Code umwandeln. Und dies sollte die direkteste Transformation sein, ohne dass Faktoren sie stören. Wir versuchen, diese störenden Faktoren zu beseitigen. Damit Sie Ihre Geschäftsaufgabe so direkt wie möglich ohne Wasser und zusätzlichen Code in eine Lösung verwandeln.

Nun, dies ist ein etwas unfairer Wettbewerb - all diese Sprachen wie Java wurden vor vielen Jahren erfunden, und Sie haben gerade.

Natürlich berücksichtigt Kotlin die Erfahrungen seiner Vorgänger. Wie jede moderne Sprache. Dies ist ein Fortschritt - wenn unter Berücksichtigung alter Mängel etwas Neues geschaffen wird. Aus gutem Grund werden in Kotlin nullfähige Typen erstellt. Gehen Sie weit, nehmen Sie ein Unternehmen, gehen Sie in ein großes Büro, sehen Sie sich die Absturzprotokolle an, und Sie werden sehen, dass die häufigste Ausnahme NullPointerException ist. Dies ist eine bekannte Tatsache, und wenn Sie eine neue Sprache erstellen, müssen Sie sie lösen. Daher achten wir in der Sprache sehr auf die Nullbarkeit. Usw. Wenn Sie die Sprache nicht abstrakt gestalten, nicht als akademische Übung, sondern versuchen, die Probleme der Menschen zu lösen, denen sie häufig begegnen, stellt sich heraus, dass die Sprache gut ist. Warum wird er geliebt? Weil er ihre Probleme löst.