Wenn jemand sich den Corda- Code ansieht, merkt er sofort, dass er in Kotlin geschrieben ist - der neuen Programmiersprache von JetBrains, die für JVM und Javascript kompiliert werden kann. Es war eine ungewöhnliche Wahl, und in diesem Artikel möchte ich einige Gründe für diese Entscheidung und die Erfahrung unseres "Jahres mit Kotlin in der Produktion" mitteilen.
Warum Kotlin?
Diese Lösung kann in zwei Teile unterteilt werden:
- Welche Plattform soll ich nutzen? JVM, .NET, Node, Python / Ruby, Go, Haskell oder etwas Kompiliertes (im Maschinencode)?
- Welche Sprache verwenden Sie, wenn Sie sich für JVM entscheiden? Java? Wenn nicht, warum dann? Und wenn nicht, was noch: Scala, Ceylon, Clojure, Kotlin, Python, Ruby, Javascript oder Haskell (weil alle eine Implementierung für JVM haben).
Die Gründe für die Wahl von JVM als Plattform sind in der Unternehmensanwendungsumgebung bekannt, und es macht nicht viel Sinn, darüber nachzudenken. Es genügt zu sagen, dass die Auswahl nur auf JVM und .NET beschränkt ist, wenn Sie eine skalierbare, threadsichere, plattformübergreifende Laufzeit mit Garbage Collection und vielen gut dokumentierten Bibliotheken benötigen, die grundlegende Geschäftsprobleme lösen.
Zu Beginn der Arbeiten an Corda hatte das Projekt keinen Namen und es war schwer vorstellbar, dass es sich in Zukunft zu einem Produkt entwickeln wird. Als das Projekt, aus dem Corda wurde, im Dezember 2015 (an meinem ersten Arbeitstag) begann, gab es keinen Plan, ein neues verteiltes Buchhaltungssystem für Unternehmen zu schaffen. Corda begann als eine Reihe von Prototypen zur Erforschung neuer Ideen und Anforderungen, an denen die Arbeitsgruppe für Konsortialarchitektur interessiert war, insbesondere im Zusammenhang mit der eingeschränkten Sichtbarkeit der Daten und dem Datenmodell, das die Skalierbarkeit des „UTXO-Satzes von Transaktionsausgabearrays“ bietet. zusammen mit der Programmierbarkeit von imperativen Ethereum-Smart-Verträgen im Allgemeinen.
Aufgrund der Tatsache, dass nicht klar war, ob diese Prototypen zu etwas werden oder einfach als Information für andere Produkte auf dem Markt dienen würden, standen wir vor einer schwierigen Wahl. Einerseits wollten wir Algorithmen und Datenstrukturen schnell und produktiv untersuchen. Auf der anderen Seite sollte es eine potenzielle Möglichkeit geben, ein großes Unternehmensprodukt zu entwickeln und schnell Mitarbeiter dafür einzustellen.
Java hat diese Anforderungen definitiv erfüllt, aber der Mangel an modernen Fähigkeiten in der Sprache verringert die Produktivität und implizit die Moral der Entwickler erheblich.
Dynamische Typisierung wurde nicht berücksichtigt - die Vorteile der Korrektheit, der Entwicklungstools und der Leistung, die durch statische Typisierung erzielt werden, sind zu groß, um vernachlässigt zu werden.
Sprachen, die sich grundlegend von den beliebtesten unterscheiden, wurden ebenfalls nicht berücksichtigt, weil Wir wollten Finanzexperten einstellen können. Und obwohl es durchaus möglich ist , ein Team um eine Sprache wie Haskell zu bilden , schien es riskant, eine Person mit ernsthafter Bankerfahrung und faulen (faulen) reinen (funktionalen) Sprachen zu finden, die zufällig in London leben. Darüber hinaus implizierte die Natur des Produkts, dass unsere "Benutzer" tatsächlich Entwickler von Plugins und Anwendungen sind, die die Plattform verwenden, und es macht keinen Sinn, von ihnen zu verlangen, völlig neue Paradigmen und Tools zu lernen. Unsere Wahl der Sprache sollte die Benutzer nicht zu sehr einschränken.
Infolgedessen blieben uns diese Anforderungen bei Kotlin, Scala und Ceylon. Diese Sprachen sind sehr ähnlich und sehr interessant. Wir haben uns aus folgenden Gründen für Kotlin entschieden:
- Fast nahtlose Integration mit Java
- Insbesondere verwenden Kotlin-Programme eine erweiterte (vom Compiler erweiterte) Version der Standard-JDK-Sammlungen, wodurch sichergestellt wird, dass keine Integrationsprobleme aufgrund der Verwendung anderer Sammlungsbibliotheken auftreten. Wir senden und empfangen Sammlungen überall zu und von Java-Bibliotheken. Daher ist es wichtig, dass dies keine Probleme verursacht.
- Aus den Kotlin-Klassen erhalten wir eine einfach aussehende Java-API mit den Methoden
get / set / is entsprechend den Typen. Hierfür sind keine besonderen Anmerkungen oder sonstigen Aktionen erforderlich. Aus dem Grund, dass Corda eine API bereitstellt, die für die transparente Verwendung durch Java-Entwickler entwickelt wurde, ist dies ein großer Vorteil: Aus gewöhnlichem Code erhalten Sie eine API, die nicht mit nur wenigen Einschränkungen von der Java-API unterschieden werden kann (zum Beispiel erfordert das explizite Abfangen geprüfter Ausnahmen von Java explizite Methodenanmerkung)
- Das Einfügen kleiner Funktionen wie
map / filter / fold / groupBy (anstatt zu hoffen, dass die JVM dies selbst erledigt) wird vom Compiler ausgeführt. Leider beseitigt der JIT JVM-Compiler, obwohl er insgesamt ausgezeichnet ist, nicht in allen Fällen den Aufwand für die häufige Verwendung von Funktionen höherer Ordnung. Die Verwendung von Kotlin gleicht dies aus und ermöglicht es Ihnen, die Programmausführung innerhalb von Lambda-Funktionen zu steuern (Hinweis: zum Beispiel nicht lokale Rückgabe). Dies ist eine der wenig bekannten, aber gleichzeitig nützlichen Funktionen. Weil Überall, wo wir Code in einem solchen funktionalen Stil schreiben, können wir, wenn er schlecht in Maschinencode übersetzt wird, Leistungsprobleme für uns selbst verursachen. - Aufgrund der Tatsache, dass der Code auf Kotlin in einen ziemlich ähnlichen Java-Code übersetzt wird, funktionieren fast alle vorhandenen Java-orientierten Tools sofort . Dies gilt nicht immer für andere Sprachen. Quasar hat beispielsweise Schwierigkeiten, Scala-Code zu instrumentieren, da Methodenanmerkungen erforderlich sind, und Scala übersetzt Lambdas in Methoden, die nicht mit Anmerkungen versehen werden können. Kotlin-Lambdas sind normalerweise eingebettet (siehe oben) oder können anderweitig kommentiert werden.
- Hervorragende Dokumentation und eine winzige Standardbibliothek machen das Lernen sehr schnell. Wir haben in unseren offenen Stellen nicht angegeben, dass Erfahrung bei Kotlin erforderlich ist, und wir haben Leute ohne sein Wissen eingestellt, die 1-3 Jahre Zeit hatten, wonach ein neues Mitglied des Teams in der Lage war, idiomatischen Code zu schreiben.
- Basierend auf der Auswahl der Kandidaten, die uns interviewt haben, ist IntelliJ die beliebteste IDE (sie hatten eine freie Auswahl an Tools). Unter den Post-Java-Sprachen unterstützt IntelliJ Kotlin am besten.
- Ich hatte bereits eine zufriedenstellende Erfahrung mit ihm und war mir daher sicher, dass ihn auch seine neuen Kollegen mögen würden.
Wenn Kotlin nicht wäre, hätten wir uns wahrscheinlich für Scala entschieden: Kotlin ist weitgehend davon inspiriert und beide sind gute Sprachen.
Unser Jahr mit Kotlin
Wie ist es - ein Jahr, um im Kontext einer Unternehmensanwendung mit einer neuen Sprache zu arbeiten?
Das Wichtigste war ohne Zweifel, von Kollegen zu hören, dass sie wirklich gerne mit ihm arbeiten. Die Programmiersprache ist eine persönliche Angelegenheit für alle, und die Leute haben normalerweise eine bestimmte Meinung zu dieser Angelegenheit. Wenn Sie als erste Aufgabe bei einem neuen Job jemanden bitten, eine neue Sprache zu lernen, und nicht einmal im Voraus davor warnen, besteht immer das Risiko, dass ein Kollege ihn einfach hasst und ihn eher nervig findet, als seine Produktivität zu steigern. Dies ist jedoch nicht der Fall.
Im Folgenden sind einige der Probleme aufgeführt, die häufig in einer Unternehmensentwicklungsumgebung nach Java / C # auftreten, auf die wir selbst gestoßen sind:
- Der Code sieht unterschiedlich aus, je nachdem, wer ihn geschrieben hat. Im Allgemeinen kein so großes Problem. Im Gegensatz zu Go, das einen bestimmten Designstil erfordert, kann der Kotlin-Code verschiedener Autoren unterschiedlich aussehen. IntelliJ verfügt jedoch über ein Formatierungswerkzeug, das einen einheitlichen Codebasisstil bietet. Es ist eingeschränkter als bei Java, aber das reicht aus. Ein subtileres Problem, insbesondere bei Scala-Code, ist der Gegensatz von Java-OOP und Haskell-FI-Codierungsstil. Scala-Code, der Bibliotheken wie Scalaz verwendet , kann für Entwickler, die eine Verbesserung von Java erwarten, schwierig zu lesen sein . In dieser Debatte ist Kotlin ziemlich fest auf der Seite des verbesserten Java. Und obwohl funktionale Programmierung, in gewisser Weise, möglicherweise auf Kotlin, hat sich die Community (zumindest vorerst) nicht in Lager aufgeteilt. Wir hatten Fälle, in denen der Code so geschrieben wurde, als wäre es Haskell, aber er wurde auf Codereview ausgearbeitet.
- Bibliotheken In Corda verwenden wir mehr als 50 Open Source-Bibliotheken und es gab keine Probleme mit irgendwelchen. Wir haben niemals Wrapper oder Adapterschichten geschrieben. Da Build-Systeme in Projekten auf Kotlin, Maven oder Gradle normalerweise verwendet werden, gibt es keinen offiziellen Kotlin-spezifischen Ersatz für diese Tools (obwohl Gradle die Kotlin-Unterstützung als neue Skriptsprache eingeführt hat!).
- DSL und SQL. C # hat LINQ, Java hat JOOQ und Kotlin hat Exposed . Dies ist einer der Bereiche, in denen Kotlin etwas schwächer ist als seine Konkurrenten. Exposed ist ein hervorragendes Beispiel für die Verwendung der Kotlin-Funktionen zum Erstellen von DSL, aber die Bibliothek selbst verfügt über eine instabile API und ist ein sekundäres Projekt. JOOQ kann natürlich mit Kotlin verwendet werden, und rückblickend scheint dies die bevorzugte Option zu sein.
- IDE / Toolkit. Das Kotlin-Plugin für IntelliJ wurde natürlich von JetBrains geschrieben und ist insgesamt großartig. Im Vergleich zur Java-Unterstützung ist es jedoch weniger ausgefeilt. Neue Editorfunktionen wie ein Parameterhinweis müssen manuell nach Kotlin portiert werden, und die Unterstützung selbst bleibt in der Regel hinter viel älteren Java-Plug-Ins zurück. Wir haben auch festgestellt, dass das IDE-Plugin häufig über interne Fehler informiert, obwohl die Häufigkeit von IDE-Ausnahmen im Laufe des Jahres erheblich zurückgegangen ist (und es scheint, dass sie nichts beeinflussen). Die Verwendung anderer Tools verursacht ebenfalls keine Probleme, da Was für Java geschrieben ist, funktioniert normalerweise sofort . Eine Ausnahme bilden Tools, die mit Quellcode anstelle von Bytecode arbeiten und offensichtlich nicht wiederverwendet werden können. Mit all dem sind der Kotlin-Compiler und das IDE-Plugin auch ein Jahr nach der Veröffentlichung von 1.0 nicht so debuggt wie im Fall von Java. Höchstwahrscheinlich werden Sie nie auf interne Fehler in
javac stoßen, aber obwohl dies sehr selten der javac ist, sehen wir sie immer noch in Kotlin. - Erkennung durch Benutzer. Corda-Benutzer sind meist große und konservative Finanzinstitute. Solche Unternehmen bevorzugen die Verwendung gängiger, gut etablierter Sprachen. Kotlin, weder der eine noch der andere, sorgte zu der Zeit, als wir anfingen, eindeutig für Überraschung. "Warum Kotlin?" - Dies ist eine Frage, die im vergangenen Jahr praktisch verschwunden ist, weil Die Leute schauten genauer hin und stellten fest, dass dies nicht so riskant ist, wie es normalerweise bei neuen Programmiersprachen der Fall ist. Wir haben auch versucht, die Einführung zu erleichtern, indem wir Codebeispiele bereitgestellt haben, die zeigen, dass für das Erstellen von Anwendungen mithilfe der Plattform keine Kotlin-Kenntnisse erforderlich sind. Die Ergebnisse waren nicht so erfolgreich - viele Entwickler, die zum ersten Mal mit Corda zusammenarbeiten, beginnen immer noch damit, Kotlin zu erkunden. Es ist nicht sehr klar, ob dies das Ergebnis der Tatsache ist, dass wir unzureichend Java-orientierte Anwendungsbeispiele und Dokumentationen bereitgestellt haben, oder ob dies nur eine gute Ausrede für das Erlernen eines neuen coolen Tools ist. Wir wurden auch durch die zunehmende Einführung von Kotlin in großen Investmentbanken unterstützt. Im vergangenen Jahr haben wir von mehreren Mitgliedern des Konsortiums gehört, dass ihre internen Entwicklungsteams ernsthaft nach Kotlin für ihre eigenen Produkte gesucht haben. Dies ist häufig auf die Verfügbarkeit von Tools zurückzuführen, die Java in Kotlin konvertieren und eine wesentlich weniger schmerzhafte Integration in die vorhandene Codebasis ermöglichen.
- Kommerzielle Unterstützung. Das Risiko der Verwendung wenig bekannter Sprachen besteht darin, dass sie möglicherweise nicht mehr entwickelt werden oder Ziele haben, die nicht mit den Anforderungen rund um das Produkt, die Benutzergemeinschaft, übereinstimmen (bei Forschungssprachen besteht das Hauptziel der Entwickler beispielsweise darin, wissenschaftliche Artikel zu erstellen). Der Hauptgrund, warum wir uns bei Kotlin sicher fühlen, ist, dass JetBrains ein stabiles, profitables Unternehmen ist, das seit mehr als 15 Jahren auf dem Markt ist. JetBrains begann schnell , sein eigenes Werkzeug zu probieren , indem Kotlin in den Code der Hauptprodukte eingeführt wurde. Das Risiko einer Beendigung der Unterstützung ist daher eher gering. Darüber hinaus ist JetBrains bereits ein Unternehmen mittleren Alters, und sein Zielmarkt (IDE und Entwicklertools) ist nicht mehr neu oder besonders modisch, was das Risiko einer möglichen Übernahme des Unternehmens verringert, was zu unvorhersehbaren strategischen Änderungen führen kann. Und trotz des Fehlens eines kommerziellen Support-Pakets für Kotlin behebt das Team in der Praxis schnell bekannte Probleme. Derzeit beabsichtigt JetBrains, das nächste Sprachupdate nach einem Jahr seit Release 1.0 zu veröffentlichen. Dieser Release-Zyklus ähnelt dem Entwicklungszyklus im Unternehmensumfeld.
Schlussfolgerungen?
Wir bedauern nicht: Die Wahl einer jungen Sprache zu Beginn dieses Projekts war zwar ein Risiko, aber ausgewogen. Er hat gute Arbeit für uns geleistet und wir würden unsere Wahl nicht ändern.