Die Zahl der Kotlin Nutzer lässt sich an einer Hand abzählen. So sind Designfehler auch nicht offensichtlich und alles scheint neu und besser. Sobald die Userbase auf eine nennenswerte Zahl steigt, dann wird offensichtlich, dass es nicht besser ist als die anderen Sprachen. Nur halt lahm und ohne ordentliche Libraries wie die etablierten Sprachen. Hauptsache was eigenes und neuer...
Wenn Kotlin Java ersetzen und obsolet machen soll, dann ist die Nutzung von Java Bibliotheken ein Widerspruch in sich. D.h. alles sollte in Kotlin programmiert und gepflegt werden. Niemand hat Bock drauf, keiner bezahlt es einem.
Schneller als Java wird es als VM Sprache auch nicht. Dabei ist Java schon ne lahme Krücke [1]. Dort wo es an Performance braucht, da geht's für Java ohnehin über JNI auf C oder C++ und damit auch auf GPGPUs, siehe Android.
Man muss schon Argumente aus der Nase herausziehen um da was einzigartihes zu finden. Meist lohnt sich dabn der Aufwand nicht. So wird die Sprache die nächsten Jahre vor sich her gammeln.
Außer c++ ist kaum eine Sprache schneller. Der Unterschied zu c++ ist auch nicht so toll. Für die meisten Dinge vernachlässigbar.
c++ tut man sich doch nur dann an, wenn es wirklich nötig ist. Viele Systemprogamme (schau mal Openstack an) sind heute in Python geschrieben, dass deutlich langsamer als Java ist.
Und vielleicht googlest du mal danach
mostly used programming languages
Und warum man Sprachen im Java Ökosystem nicht mixen sollte ist für mich auch nicht nachvollziehbar.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Mai 2017 um 20:12.
Naja, allein Faktor 3-5 bedeutet dass du entweder einen Tag rechnen musst oder eine ganze Woche. Gerade bei neuen Machine Learning anwendungen macht es einen immensen Unterschied.
>> Für die meisten Dinge vernachlässigbar.
Ich weiß nicht ob's die meisten Dinge sind, aber für viele schon, da gebe ich dir recht.
>> c++ tut man sich doch nur dann an, wenn es wirklich nötig ist.
Modernes C++ muss man sich nicht mehr antun. Es ist eine schöne und bequeme Sprache. Schade, dass alle Leute den C++98 Standard im Kopf haben.
>> Viele Systemprogamme (schau mal Openstack an) sind heute in Python geschrieben, dass deutlich langsamer als Java ist.
Python ist nicht Python, da gibt es immense Performance-Unterschiede. Vieles bei diesen VM Sprachen ist auch nicht vergleichbar, da sie intern so wie NumPy auf C oder FORTRAN wechseln, sobald es performancekritisch wird. Java wechselt in JNI auf C bzw. C++. Dann sieht es so aus, als ob die Sprache nicht lahm ist. Die JVMs dieser Sprachen sind meist auch in C++ geschrieben. Wären sie in Java, dann kannst du da noch einen Faktor 5 davor multiplizieren.
Da gibt es aber auch Quellen, die was anderes aussagen.
Bei java muss man auch zwischen Server und Client Mode unterscheiden. Der JIT Compiler geht im Server Mode anderes vor. In der Regel braucht er länger um "warm" zu werden. Ist aber dafür dann schneller.
Ich spreche vom Quellcode, der Berechnungen ausführt. Dort bleibt 3-5 definitiv bestehen. Unabhängig vom Server oder Client.
Nicht berücksichtigt sind dieser Dinge:
- dass z.B. die Apache Machine Learning Bibliotheken teils nur mit Double anstatt sinnvollerweise mit Float arbeiten. Das allein ist schon Faktor 2. - Mittlerweile sind die AI Algorithmen so weit frisiert, dass sie auch gut mit Half Precision zurechtkommen. Damit haben wir Faktor 4. Java bietet noch kein natives Half Precision. Hier wird der Unterschied noch eine Ordnung höher sein. - Standardisierte Bibliotheken für GPGPU existieren auch nicht. Hier ist locker Faktor 100 drin.
Wenn wir von realen Benchmarks sprechen, dann müssen auch die oberen Dinge berücksichtigt werden.
Bei synthetischen Benchmarks unter gleichen Bedingungen ist mir auch kein Benchmark bekannt, der öffentlich von vielen Teilnehmen (nicht nur einer Person) getuned wurde, bei dem Java nicht um mindestens Faktor 3 gegenüber C absackt. Die Benchmarks einzelner Personen mit wenigen Beispielen sind nur Augenwischerei um sich eine Beruhigungspille zu verschreiben.
Wer es besser kann, sollte seinen Java Code hier einreichen:
https://benchmarksgame.alioth.debian.org/
Vielleicht irre ich mich ja und es geht doch schneller.
Der Quellcode macht erstmal gar nichts...nein der berechnet nichts. Synthetische Benchmarks? Dachte Du redest von realworld-performance. Und wieso redest Du jetzt ploetzlich von C und nicht mehr von C++
Wo hast du das mit "ersetzen und obsolet machen" her? Sagen das die Kotlin-Broschüren? Das würde ich mal beiseite legen. Und auch Performance will es imho auch nicht angehen. Es soll einfach eine Alternative zu Java sein, die vielleicht (?!) mehr Komfort bietet. Vielleicht werden deine Programme wartbarer oder mächtiger dadurch. Oder du erschließt über eine simplere Sprache eine größere Nutzerschaft. Ich hatte das so als die Argumente verstanden. Selber bewerten kann ich es nicht, weil ich Kotlin nur vom Namen her kenne Aber solange ich das kombinieren kann, und solange Java auch nicht wirklich gottartig perfekt ist und in seiner Weiterentwicklung unbefriedigend voranschreitet (was ich so als Java-Outsider aufschnappe), ist das sowas wie Kotlin doch auch nicht grundverkehrt?!
Worin soll darin der Sinn liegen? Natürlich muss man an die Android Frameworks rankommen, die bekanntlich in Java geschrieben sind, um sinnvoll Apps für Android zu programmieren. Den Rest will man aber am liebsten loswerden.
Ich denke da steht alles an Libraries zur Verfügung ,was es im Java Ökosystem gibt. So ist es zumindest bei anderen Javasprachen, wie Groovy, Scala oder auch Closure. Und die lassen sich auch problemlos mischen.
Von HansiHinterseher am Fr, 19. Mai 2017 um 10:34 #
Kotlin ist eine JVM-Sprache, so wie es Scala, JRuby, Groovy u.a. sind.
Man sieht also, das es nur ein anderer Teilnehmer auf der JVM-Bühne ist. Und bisher hat es keiner geschafft die Java-Sprache von der Bühne zu schubsen.
Natürlich kann keiner der Konkurrenten schneller in der Laufzeit sein, weil alle von der JVM und den selben Bibliotheken abhängen.
Es geht bei den Konkurrenten eher um das Programmierparadigma. Um "schöneren" und "kürzeren" Code.
Das Problem das aber alle Konkurrenten haben: meistens fremdartige Syntax und viele Firmen haben schon viel Java-Code geschrieben der einfach funktioniert.
>> Man sieht also, das es nur ein anderer Teilnehmer auf der JVM-Bühne ist. Und bisher hat es keiner geschafft die Java-Sprache von der Bühne zu schubsen.
Das wird von sich aus auch nicht möglich sein, da ist Java einfach zu weit. Es sei denn Oracle macht einen großen Fehler und bleibt in der Entwicklung stehen.
C war irgendwann einmal Primus. Dann kam C++ mit neuem Paradigma. Erst die Klassen, dann die Touring vollständige Meta-Programmierung. Da kann C von der bequemlichkeit her einfach nicht mithalten. Leider sitzt Microsoft im C++ Standardisierungskomitee. MS und ein paar autistische Nerds sorgen kräftig dafür, dass C++ sich nicht wirklcih weiterentwickelt sondern nur vor sich her hinkt. Diese Trottel haben die Entwicklung kräftig eingeschränkt. Damit hat C++ die Web und GUI und Programmierung verschlafen, in der Jetzt Java dominiert. Gott sei Dank verbessert sich das ganze jetzt um C++. Es ist schon ne Schande wie lange es an Elementarrunktionen wie to_string( double ) gefehlt hat. Von vernünftig standardisierter Modularisierung mal ganz zu schweigen.
>> Es geht bei den Konkurrenten eher um das Programmierparadigma. Um "schöneren" und "kürzeren" Code.
Klar, was Viele jedoch nicht verstehen ist, dass die Zeichen nunmal begrenzt sind. Für einige Funktionen werden sie schönen Quellcode haben, später gehen ihnen die Zeichen aus und sie müssen ebenfalls Umwege und Kompromisse eingehen.
Ab da an gibt es zwei Möglichkeiten. Entweder man geht den Python-Weg und bricht mit der Kompatibilität ( 2.7 --> 3 ). Damit schafft man sich Freiraum für eine schönere Syntax und Funktionsvielfalt. Verärgert aber vielleicht damit die Hälfte der Gemeinde. Dafür sieht der Quellcode aus wie Pseudocode und ist sehr einfach zu lernen. Aber auch Python hat seine Grenzen für die, die damit professionell programmieren. Bin mal gespannt wie die Debatte um GIL endet..
Die zweite Möglichkeit ist einfach eine hässliche Syntax einzuführen ( C+98 ) und sie nach und Nach mit neuen Methoden in eine schöne zu überführen ( C+11, C++14, C++17). Leider nistet sich bei den meisten eine hässliche Syntax ein und obwohl C++ schon ewigkeiten die Garbage collection automatisch durch smart pointer erledigt, gibt es immer noch Trottel die mit delete, memset, alloc, realloc und ähnlichem Schund programmieren. Das ganze Stackoverflow ist praktisch voll davon.
Auch Java macht gerade einen Umbruch mit der Streaming Programmierung durch. Dann kommt noch Jigsaw.
Die Erfindung neuer Sprachen ist im Moment nur Ressourcenverschwendung. Die Umstellung auf eine Neue Sprache wird nichts bringen. Hinter Java steckt eine extrem große Gemeinde an Firmen und Software-Entwicklern. Da kommen Go, Kotlin, Ruby noch in 10 Jahren nicht ran, selbst wenn die Java Standardisierung und Entwicklung stehen bleibt.
Die Zahl der Kotlin Nutzer lässt sich an einer Hand abzählen. So sind Designfehler auch nicht offensichtlich und alles scheint neu und besser. Sobald die Userbase auf eine nennenswerte Zahl steigt, dann wird offensichtlich, dass es nicht besser ist als die anderen Sprachen. Nur halt lahm und ohne ordentliche Libraries wie die etablierten Sprachen. Hauptsache was eigenes und neuer...
So wie D, Swift, Go und viele andere Sprachen.
Wenn Kotlin Java ersetzen und obsolet machen soll, dann ist die Nutzung von Java Bibliotheken ein Widerspruch in sich. D.h. alles sollte in Kotlin programmiert und gepflegt werden. Niemand hat Bock drauf, keiner bezahlt es einem.
Schneller als Java wird es als VM Sprache auch nicht. Dabei ist Java schon ne lahme Krücke [1]. Dort wo es an Performance braucht, da geht's für Java ohnehin über JNI auf C oder C++ und damit auch auf GPGPUs, siehe Android.
Man muss schon Argumente aus der Nase herausziehen um da was einzigartihes zu finden. Meist lohnt sich dabn der Aufwand nicht. So wird die Sprache die nächsten Jahre vor sich her gammeln.
[1] http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html
Der Unterschied zu c++ ist auch nicht so toll.
Für die meisten Dinge vernachlässigbar.
c++ tut man sich doch nur dann an, wenn es wirklich nötig ist.
Viele Systemprogamme (schau mal Openstack an) sind heute in Python geschrieben, dass deutlich langsamer als Java ist.
Und vielleicht googlest du mal danach
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Mai 2017 um 20:12.Und warum man Sprachen im Java Ökosystem nicht mixen sollte ist für mich auch nicht nachvollziehbar.
>> Der Unterschied zu c++ ist auch nicht so toll.
Naja, allein Faktor 3-5 bedeutet dass du entweder einen Tag rechnen musst oder eine ganze Woche. Gerade bei neuen Machine Learning anwendungen macht es einen immensen Unterschied.
>> Für die meisten Dinge vernachlässigbar.
Ich weiß nicht ob's die meisten Dinge sind, aber für viele schon, da gebe ich dir recht.
>> c++ tut man sich doch nur dann an, wenn es wirklich nötig ist.
Modernes C++ muss man sich nicht mehr antun. Es ist eine schöne und bequeme Sprache. Schade, dass alle Leute den C++98 Standard im Kopf haben.
>> Viele Systemprogamme (schau mal Openstack an) sind heute in Python geschrieben, dass deutlich langsamer als Java ist.
Python ist nicht Python, da gibt es immense Performance-Unterschiede. Vieles bei diesen VM Sprachen ist auch nicht vergleichbar, da sie intern so wie NumPy auf C oder FORTRAN wechseln, sobald es performancekritisch wird. Java wechselt in JNI auf C bzw. C++. Dann sieht es so aus, als ob die Sprache nicht lahm ist. Die JVMs dieser Sprachen sind meist auch in C++ geschrieben. Wären sie in Java, dann kannst du da noch einen Faktor 5 davor multiplizieren.
>>Naja, allein Faktor 3-5 bedeutet
Da gibt es aber auch Quellen, die was anderes aussagen.
Bei java muss man auch zwischen Server und Client Mode unterscheiden.
Der JIT Compiler geht im Server Mode anderes vor.
In der Regel braucht er länger um "warm" zu werden.
Ist aber dafür dann schneller.
Ich spreche vom Quellcode, der Berechnungen ausführt. Dort bleibt 3-5 definitiv bestehen. Unabhängig vom Server oder Client.
Nicht berücksichtigt sind dieser Dinge:
- dass z.B. die Apache Machine Learning Bibliotheken teils nur mit Double anstatt sinnvollerweise mit Float arbeiten. Das allein ist schon Faktor 2.
- Mittlerweile sind die AI Algorithmen so weit frisiert, dass sie auch gut mit Half Precision zurechtkommen. Damit haben wir Faktor 4. Java bietet noch kein natives Half Precision. Hier wird der Unterschied noch eine Ordnung höher sein. - Standardisierte Bibliotheken für GPGPU existieren auch nicht. Hier ist locker Faktor 100 drin.
Wenn wir von realen Benchmarks sprechen, dann müssen auch die oberen Dinge berücksichtigt werden.
Bei synthetischen Benchmarks unter gleichen Bedingungen ist mir auch kein Benchmark bekannt, der öffentlich von vielen Teilnehmen (nicht nur einer Person) getuned wurde, bei dem Java nicht um mindestens Faktor 3 gegenüber C absackt. Die Benchmarks einzelner Personen mit wenigen Beispielen sind nur Augenwischerei um sich eine Beruhigungspille zu verschreiben.
Wer es besser kann, sollte seinen Java Code hier einreichen:
https://benchmarksgame.alioth.debian.org/
Vielleicht irre ich mich ja und es geht doch schneller.
Der Quellcode macht erstmal gar nichts...nein der berechnet nichts.
Synthetische Benchmarks? Dachte Du redest von realworld-performance.
Und wieso redest Du jetzt ploetzlich von C und nicht mehr von C++
Wo hast du das mit "ersetzen und obsolet machen" her? Sagen das die Kotlin-Broschüren? Das würde ich mal beiseite legen. Und auch Performance will es imho auch nicht angehen. Es soll einfach eine Alternative zu Java sein, die vielleicht (?!) mehr Komfort bietet. Vielleicht werden deine Programme wartbarer oder mächtiger dadurch. Oder du erschließt über eine simplere Sprache eine größere Nutzerschaft. Ich hatte das so als die Argumente verstanden. Selber bewerten kann ich es nicht, weil ich Kotlin nur vom Namen her kenne
Aber solange ich das kombinieren kann, und solange Java auch nicht wirklich gottartig perfekt ist und in seiner Weiterentwicklung unbefriedigend voranschreitet (was ich so als Java-Outsider aufschnappe), ist das sowas wie Kotlin doch auch nicht grundverkehrt?!
Bringst Du das argument auch bei Rust zu C?
Worin soll darin der Sinn liegen? Natürlich muss man an die Android Frameworks rankommen, die bekanntlich in Java geschrieben sind, um sinnvoll Apps für Android zu programmieren. Den Rest will man aber am liebsten loswerden.
Ich denke da steht alles an Libraries zur Verfügung ,was es im Java Ökosystem gibt.
So ist es zumindest bei anderen Javasprachen, wie Groovy, Scala oder auch Closure.
Und die lassen sich auch problemlos mischen.
Kotlin ist eine JVM-Sprache, so wie es Scala, JRuby, Groovy u.a. sind.
Man sieht also, das es nur ein anderer Teilnehmer auf der JVM-Bühne ist. Und bisher hat es keiner geschafft die Java-Sprache von der Bühne zu schubsen.
Natürlich kann keiner der Konkurrenten schneller in der Laufzeit sein, weil alle von der JVM und den selben Bibliotheken abhängen.
Es geht bei den Konkurrenten eher um das Programmierparadigma. Um "schöneren" und "kürzeren" Code.
Das Problem das aber alle Konkurrenten haben: meistens fremdartige Syntax und viele Firmen haben schon viel Java-Code geschrieben der einfach funktioniert.
>> Man sieht also, das es nur ein anderer Teilnehmer auf der JVM-Bühne ist. Und bisher hat es keiner geschafft die Java-Sprache von der Bühne zu schubsen.
Das wird von sich aus auch nicht möglich sein, da ist Java einfach zu weit. Es sei denn Oracle macht einen großen Fehler und bleibt in der Entwicklung stehen.
C war irgendwann einmal Primus. Dann kam C++ mit neuem Paradigma. Erst die Klassen, dann die Touring vollständige Meta-Programmierung. Da kann C von der bequemlichkeit her einfach nicht mithalten. Leider sitzt Microsoft im C++ Standardisierungskomitee. MS und ein paar autistische Nerds sorgen kräftig dafür, dass C++ sich nicht wirklcih weiterentwickelt sondern nur vor sich her hinkt. Diese Trottel haben die Entwicklung kräftig eingeschränkt. Damit hat C++ die Web und GUI und Programmierung verschlafen, in der Jetzt Java dominiert. Gott sei Dank verbessert sich das ganze jetzt um C++. Es ist schon ne Schande wie lange es an Elementarrunktionen wie to_string( double ) gefehlt hat. Von vernünftig standardisierter Modularisierung mal ganz zu schweigen.
>> Es geht bei den Konkurrenten eher um das Programmierparadigma. Um "schöneren" und "kürzeren" Code.
Klar, was Viele jedoch nicht verstehen ist, dass die Zeichen nunmal begrenzt sind. Für einige Funktionen werden sie schönen Quellcode haben, später gehen ihnen die Zeichen aus und sie müssen ebenfalls Umwege und Kompromisse eingehen.
Ab da an gibt es zwei Möglichkeiten. Entweder man geht den Python-Weg und bricht mit der Kompatibilität ( 2.7 --> 3 ). Damit schafft man sich Freiraum für eine schönere Syntax und Funktionsvielfalt. Verärgert aber vielleicht damit die Hälfte der Gemeinde. Dafür sieht der Quellcode aus wie Pseudocode und ist sehr einfach zu lernen. Aber auch Python hat seine Grenzen für die, die damit professionell programmieren. Bin mal gespannt wie die Debatte um GIL endet..
Die zweite Möglichkeit ist einfach eine hässliche Syntax einzuführen ( C+98 ) und sie nach und Nach mit neuen Methoden in eine schöne zu überführen ( C+11, C++14, C++17). Leider nistet sich bei den meisten eine hässliche Syntax ein und obwohl C++ schon ewigkeiten die Garbage collection automatisch durch smart pointer erledigt, gibt es immer noch Trottel die mit delete, memset, alloc, realloc und ähnlichem Schund programmieren. Das ganze Stackoverflow ist praktisch voll davon.
Auch Java macht gerade einen Umbruch mit der Streaming Programmierung durch. Dann kommt noch Jigsaw.
Die Erfindung neuer Sprachen ist im Moment nur Ressourcenverschwendung. Die Umstellung auf eine Neue Sprache wird nichts bringen. Hinter Java steckt eine extrem große Gemeinde an Firmen und Software-Entwicklern. Da kommen Go, Kotlin, Ruby noch in 10 Jahren nicht ran, selbst wenn die Java Standardisierung und Entwicklung stehen bleibt.
> und ein paar autistische Nerds
War echt nicht nötig!