1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Kotlin: Das bessere Java
  6. Them…

Kotlin, der Flopp des Jahrzehnts

Für Konsolen-Talk gibt es natürlich auch einen Raum ohne nerviges Gedöns oder Flamewar im Freiraum!
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Kotlin, der Flopp des Jahrzehnts

    Autor: foobarJim 06.11.20 - 17:32

    twothe schrieb:
    --------------------------------------------------------------------------------

    > Da Kotlin und Java auf der gleichen JVM laufen wird am Ende ca. der selbe
    > Bytecode raus kommen. Kotlin kann keine "Magic" auf der JVM machen die Java
    > nicht auch könnte.

    Jein. Auf Bytecode-Ebene ist man natürlich auf einem Level. Was aber sprachlich dargestellt werden kann ist unterschiedlich. Kotlin kann z.B. Type-Erasure nicht umgehen, oder nur mit Tricks wie inline-Functions, da dies aufgrund von Beschränkungen der JVM halt nun mal so ist. Auf sprachlicher Ebene gibt es aber durchaus Features die Java nicht kann, die aber das Leben einfacher machen. Warum hat es z.B. so lange gedauert bis Java Multiline-Strings konnte. Das ist keine Magic, aber der Java-Compiler konnte es schlicht und ergreifend vor Java 13 (?) nicht.

    > - Coroutinen: wer irgendwie denkt Coroutinen wäre besser als nebenläufige
    > Threads hat das ein oder andere Konzept nicht verstanden. Support für
    > Coroutinen gibt es in Java schon seit 1.0, dass das niemand benutzt hat
    > gute Gründe: es gibt wesentlich bessere Optionen. Das Argument das Android
    > single-threaded sei und das Coroutinen Vorteile hätten ist einfach nur in
    > jeder Hinsicht falsch.

    Coroutines heute und das was Java zu 1.0-Zeiten konnte unterscheiden sich dann doch aber ein wenig. Warum wohl will Java hier mit Project Loom nachziehen. Coroutines sind einfach deutlich effizienter als Threads. Sie mögen nicht für alles geeignet sein, aber für die meisten Anwendungen dürfte es performanter sein auf Coroutines mit entsprechend dimensionierten Threadpools zu setzen und die Thread-Allokierung dem entsprechenden ExecutionContext zu überlassen.

    > - Checked Exceptions: bei Kotlin darf ich also zu erwartende Programmfehler
    > einfach ignorieren. Großartig! Dann crashen wir wieder auf den Desktop wie
    > damals 1998.

    Unchecked Exceptions und checked Exceptions werden aber keineswegs konsistent bei Java verwendet. Man muss ja auch unterscheiden, ob ein Fehler aufgrund einer falschen Eingabe oder aufgrund z.B. Speichermangels oder eines Programmierfehlers fehlschlägt. Ein ganz bekanntes Beispiel ist z.B. `Integer.parseInt(String s)`. Warum um Himmels willen ist das eine unchecked Exception? Ist doch klar, dass man das abfangen muss. Letztlich wäre es aber trotz allem viel besser man hätte ein Rückgabetyp wie z.B. `Either` oder `Result` und würde Exceptions nur bei "harten" Fehlern, wie z.B. Speichermangel, verwenden.

    > - Data Classes: gibt es in Java schon seit einer Ewigkeit und heißt dort
    > Bean. Data-Klassen in Kotlin sind nichts anderes als Beans, die schlicht
    > und ergreifen ihre Setter und Getter verstecken. Man darf darüber streiten
    > was besser ist, ich persönlich mag keine Code Magic.

    Na, dann warten wir mal ob du Records verwenden wirst.

    > - Smart Casts: ganz nett das man sich hier ein paar Buchstaben spart, aber
    > wie oben schon erwähnt: ich bin kein Freund von Code Magic.

    Hmm, du würdest dich wundern was dir dein Java-Compiler alles in Bytecode übersetzt von dem du dachtest es sei keine Code-Magic.

    > - Type Inteference: Das wird immer so gehyped das man keinen Typ angeben
    > muss. In JavaScript, einer Sprache wo das schon seit Anbeginn geht, tut man
    > gerade alles um das zu unterbinden, weil es in größeren Projekten eine
    > Katastrophe und häufige Fehlerquelle ist. Das ist also bei Kotlin kein
    > Vorteil sondern ein Nachteil.

    Das kann man doch nicht mit JavaScript vergleichen. Typinferenz geht nur da wo der Typ zur Compile-Zeit klar ist.

    Manchmal ist Java halt auch sehr geschwätzig. Z.B. wenn man einen Typ nochmal bei der Variablendefinition angibt obwohl durch den zugewiesen Wert sowieso der Typ klar ist. Wobei ich auch glaube, dass Java hier mittlerweile auch teilweise Typinferenz anbietet.

    > - Functional Programming: in Java seit Java 8 voll supported, also seit 6
    > Jahren. Wenn man das offizielle Release-Date von Kotlin nimmt, dann kann
    > Java schon 2 Jahre länger Functional.

    Selbst Kotlin kratzt nur ein wenig an der Oberfläche funktionaler Programmierung. Allein die Unterstützung von Lambdas macht noch keine funktionale Sprache aus.

    > Kotlins Vorteile schrumpfen also im Fazit auf ein paar Tipp-Unterstützungen
    > zusammen.

    Nein. Kotlin ist keine komplett andere Sprache wie z.B. Scala. Es ist mehr oder weniger Java mit Syntax-Sugar (plus ein paar Features wie z.B. Coroutines). Aber vieles daran macht Kotlin damit einfacher und wenige sperrig als es in Java möglich ist. Und viele der Features, die Kotlin Java vorraus hat, werden bei Java in den nächsten Releases nachgezogen. Ich frage mich, ob du diesen Features dann immer noch so ablehnend gegenüber stehst.

  2. Re: Kotlin, der Flopp des Jahrzehnts

    Autor: spyro2000 06.11.20 - 18:34

    > Da Kotlin und Java auf der gleichen JVM laufen wird am Ende ca. der selbe
    > Bytecode raus kommen. Kotlin kann keine "Magic" auf der JVM machen die Java
    > nicht auch könnte.

    Dann könnte man jede native Programmiersprache auch als überflüssig bezeichnen solange kompatibler Maschinencode dabei raus kommt.

    > - NullPointerExcptions sind keine "Frustration für alle Programmierer"
    > sondern nur für Einsteiger. Jeder bessere IDE zeigt zudem potentielle
    > NullPointer an, wenn man überhaupt noch so programmiert das sie auftreten
    > können.

    Klar, NPEs kommen im Alltag ja kaum vor. ;)
    Vor allem, da Java einem ja soviel Mittel in die Hand gibt, ob sich davor zu schützen. Zum Beispiel eine @NotNull- bzw. @Nullable Annotation, die der Compiler ignoriert und an die sich der Entwickler "bitte halten soll".

    Nein, sorry. Du hast offenbar einfach nicht verstanden, wie tief das Konzept von Null-Safety in eine Sprache integriert sein muss damit sie wirklich funktioniert. Und Kotlin ist genau darauf ausgelegt.

    > - Extend Functions sind Klassen die um eine Funktion erweitert wurden. Also
    > exakt das was auch ein extends in Java macht. Man kann über die nötige
    > Formalie streiten, das Klassen aber spontan neue Funktionen haben können
    > hat schon in JavaScript immer für viel Probleme gesorgt.

    Nein, du hast nicht verstanden, was Extension Methods sind. Die werden statisch zur Compiletime reingelinkt, die Originalklasse wird nicht verändert. Auch der Scope der Extension-Method ist genau beschränkt und hat keine Auswirkungen z.B. auf Klassen außerhalb des betreffenden Packages. Der Vergleich mit Javascript ist hier komplett deplaziert.

    > - Coroutinen: wer irgendwie denkt Coroutinen wäre besser als nebenläufige
    > Threads hat das ein oder andere Konzept nicht verstanden. Support für
    > Coroutinen gibt es in Java schon seit 1.0, dass das niemand benutzt hat
    > gute Gründe: es gibt wesentlich bessere Optionen. Das Argument das Android
    > single-threaded sei und das Coroutinen Vorteile hätten ist einfach nur in
    > jeder Hinsicht falsch.
    >

    Und schon wieder falsch. Coroutines sind eben gerade keine Threads und sind auch für das OS und die CPU zunächst mal komplett transparent. Du kannst mal versuchen was passiert, wenn du einfach mal auf Verdacht 100.000 Threads erzeugt und dann wild dazwischen hin- und herspringst. ;)

    Siehe auch https://www.baeldung.com/kotlin-coroutines

    > - Checked Exceptions: bei Kotlin darf ich also zu erwartende Programmfehler
    > einfach ignorieren. Großartig! Dann crashen wir wieder auf den Desktop wie
    > damals 1998.

    Stimmt, da ist ein "ex.printStackTrace(...)" natürlich viel nützlicher... Einfach um die Main-Methode ein try-catch rum machen - fertig. Deshalb muss ich aber nicht an 20 Stellen im Code beim Parsen jeder blöden URI oder etwas JSON die selbe dumme Exception abfangen. Ganz zu schweigen davon, dass sich das Konzept schlicht nicht mit funktionaler Programmierung verträgt (wie der Java-Compiler übrigens selbst in solchen Fällen meldet)...

    > - Data Classes: gibt es in Java schon seit einer Ewigkeit und heißt dort
    > Bean. Data-Klassen in Kotlin sind nichts anderes als Beans, die schlicht
    > und ergreifen ihre Setter und Getter verstecken. Man darf darüber streiten
    > was besser ist, ich persönlich mag keine Code Magic.

    Wenn "Code Magic" dein persönliches Kürzel für "verstehe ich nicht, geh weg!" ist, dann ist das nachvollziehbar. Aber nein, eine Data Class ist keine Bean. Eine Data Class ist nicht nur sehr viel kompakter und besser wartbar, sie bringt auch schon Implementierungen für toString(), hashCode() und equals() mit. Und bietet einen Copy-Construktor. Und sie "versteckt auch keine Getter und Setter", denn braucht Kotlin dank Properties nicht. Getter/Setter sind einfach ein Design-Pattern für Java, eben deshalb, weil Java keine Properties hat...

    > - Smart Casts: ganz nett das man sich hier ein paar Buchstaben spart, aber
    > wie oben schon erwähnt: ich bin kein Freund von Code Magic.

    Ein tolles Argument. Ja, viel Spaß beim manuellen Vercasten. Gerade für größere Refactoring ist das bestimmt ein Quell der Freude. :)

    > - Type Inteference: Das wird immer so gehyped das man keinen Typ angeben
    > muss. In JavaScript, einer Sprache wo das schon seit Anbeginn geht, tut man
    > gerade alles um das zu unterbinden, weil es in größeren Projekten eine
    > Katastrophe und häufige Fehlerquelle ist. Das ist also bei Kotlin kein
    > Vorteil sondern ein Nachteil.
    >
    (seufz)

    Auch der Vergleich ist einfach falsch und zeigt, wie wenig du von Kotlin verstanden hast. Typinferenz hat nichts mit schwacher oder dynamischer Typisierung zu tun. Ein

    val myName = "Klaus"

    erzeugt exakt den selben Bytecode wie

    val myName: String = "Klaus".

    Nur eben automatisch. Und praktisch allen anderen Sprachen wie C# schon seit Ewigkeiten Standard. Aus gutem Grund.

    > - Functional Programming: in Java seit Java 8 voll supported, also seit 6
    > Jahren. Wenn man das offizielle Release-Date von Kotlin nimmt, dann kann
    > Java schon 2 Jahre länger Functional.

    Nein, weil Java nur (wie so oft) das absolut Allernötigste unterstützt. Gegen Kotlin gewinnst du hier mit Java keinen Blumentopf: https://kotlinlang.org/docs/tutorials/kotlin-for-py/functional-programming.html

    > Kotlins Vorteile schrumpfen also im Fazit auf ein paar Tipp-Unterstützungen
    > zusammen.

    Haja, ja klar :D
    In deiner kleinen Welt vielleicht: https://hackr.io/blog/kotlin-vs-java

  3. Re: Kotlin, der Flopp des Jahrzehnts

    Autor: minnime 06.11.20 - 23:32

    Die Tätigkeit des Programmierers ist eher mit der des Brückenbauarbeiters, nicht der des Ingenieurs zu vergleichen.

  4. Re: Kotlin, der Flopp des Jahrzehnts

    Autor: Trockenobst 07.11.20 - 03:57

    apoth90 schrieb:
    --------------------------------------------------------------------------------
    > Jaja, C++ ist eine total sichere und produktive Sprache... wenn man erstmal
    > 20 Jahre Erfahrung damit hat.

    Ich habe mit Gefühlt 10% der C++99 Features ganze Systeme gebaut. Damals war Java zu lahm und C noch anfälliger als heut (mangels Tooling). Wenn du nicht total durchgeknallte Dinge mit dem Speicher, selbstgeschriebenen Listen und bizarre Pointerscheiße für 20% mehr Performance(!!!!!) gemacht hast, war Kinderfasching C++ absolut ok. Bis heute wird das System (inzwischen auf C++11 gehoben und massiv parallelisiert) immer noch aktiv genutzt und damit Geld verdient.

    Defensive Programmierung, Sicherheitsdenken etc. ist in allen Sprachen ein Thema. Nicht jeder schreibt an der nächsten selbstfahrendem Auto oder an der Triangulierung von Flugzeugen am Flughafen. Entsprechend investiert man in Sicherheit. Die meisten Systeme werden nicht mit Zero Days gehackt, sondern durch alberne Defaults.

  5. Re: Kotlin, der Flopp des Jahrzehnts

    Autor: Trockenobst 07.11.20 - 04:11

    spyro2000 schrieb:
    --------------------------------------------------------------------------------
    > > - Functional Programming: in Java seit Java 8 voll supported, also seit
    > Nein, weil Java nur (wie so oft) das absolut Allernötigste unterstützt.
    > Gegen Kotlin gewinnst du hier mit Java keinen Blumentopf: kotlinlang.org

    Spätestens wenn man (ruhig experimentell genannte) Erweiterungen wie Arrow nutzt, ist Java ein zwei Sonnensysteme davon entfernt: https://arrow-kt.io/docs/patterns/error_handling/

    Ich arbeite schon ewig mit Java und nichts hat mich in der letzten Jahren so beeindruckt wie funktionale Erweiterungen. Die Entwickler in einem großen Team zu zwingen fachliche Denkweisen (Option, Either) zu entwickeln, das man nicht alles über "Exception Management" lösen muss, ist schon sehr viel besser. C# leidet genauso darunter und dort werden die selben Diskussionen geführt.

    Bis in den Sommer habe ich an einem Prototypen in Kotlin gearbeitet, und ich hatte schon seit langem nicht mehr so viel Spass, gerade im Kontext von Microservice Webanwendung, Datenbank und Cloud APis. Bis auf das leider noch rudimentäre Tooling (speziell bei den Auswertungen zur Codequalität) kann man schon sehr produktiv damit arbeiten.

  6. Re: Kotlin, der Flopp des Jahrzehnts

    Autor: nikeee13 07.11.20 - 08:36

    pioneer schrieb:
    --------------------------------------------------------------------------------
    > twothe schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > ... Geschwurbel
    >
    > Ego 1, Ahnung 0

    Bin auch kein Fan der Java-Welt, aber Pioneer stimme ich zu.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. TecAlliance GmbH, Würzburg, Maastricht (Niederlande)
  2. Volkswagen Vertriebsbetreuungsgesellschaft mbH, Wolfsburg, Berlin
  3. Landeshauptstadt München, München
  4. IT-Systemhaus der Bundesagentur für Arbeit, Nürnberg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 15,99€
  2. 10,79€
  3. 10,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme