Du hast aber auch keine Argumente parat, oder? Wir sollten hier Geschmack und Fakten klar trennen.
Das wichtigste Feature an der Sprache ist IMHO die Null-Safety. Deswegen glaube ich auch, dass es so viel mehr bringt, wenn zukünftig mehr Kotlin statt Java oder Scala geschrieben wird. Ich bin bzgl. null immer äußerst vorsichtig und passe immer auf, dass keine NPEs auftreten. Trotzdem findet Kotlin, wenn ich meinen Java Code von IntelliJ nach Kotlin übersetzen lasse, pro 100 Zeilen etwa 1 bis 2 Produktions-Relevante NPEs in meinem Code, welche auch meine Unit-Tests nicht aufgedeckt haben (Das ist abzüglich der Fälle, in welchen die NPE nur theoretisch auftreten kann, praktisch aber andere Checks das verhindern). In "schlechterem" Code findet Kotlin z.T. 5-6 wichtige NPEs pro 100 Zeilen. (sorry, klingt arrogant, ist aber so).
Perspektivisch macht es IMO sogar sinn, irgendwann null gar nicht mehr zu erlauben. Siehe dazu warum überhaupt erst das einführen von Null-Pointern ein schwerer Fehler war.
Außerdem halte ich die Properties ein unglaublich wichtiges Feature, das zudem auch noch besser umgesetzt ist als bei der Konkurrenz C#. Methoden sollten für Dinge verwendet werden, die aus Sicht des Nutzers eines Objektes tatsächlich etwas tun. Getter und Setter sind ja nur Mittel zum Zweck, weil Java nix anderes kann. Java hätte hier schon lange aufholen sollen.
Meiner Erfahrung nach macht Kotlin nur mit einer IDE Sinn. Gerade das Operator-Overloading und die Extension-Methods können sehr schwer nachvollziehbar sein, wenn man keine IDE zur Hand hat. Hat man das allerdings (und ernsthaft, wann habt ihr das letzte mal ernsthaften Code außerhalb einer IDE geschrieben?) ist es eine Sache von 2 Keystrokes und man weiss, welche Funktion aufgerufen wird; samt Docs dazu. Deshalb, in einer IDE, machen es diese zwei Features (Extension-Methods und Operator-Overloading) möglich, Code zu schreiben, der weniger Overhead hat und die eigentliche Sache des Codes viel schneller auf den Punkt bringt.
Beim impliziten it Parameter gebe ich [USER=23524]@Flown[/USER] Recht: der ist in komplizierteren Verkettungen von Lambda-Ausdrücken, wo nicht klar ist, auf was er sich jetzt bezieht, eher kontraproduktiv.
