Czy Kotlin naprawdę jest lepszy od C#?

Często w dyskusjach na temat "Java czy .NET" pojawiają się głosy, że na JVM są też języki nie dość, że lepsze od Javy, to lepsze od C#. Na ile jest w tym prawdy? Czy C# naprawdę jest daleko w tyle za Kotlinem? I czy może się to zmienić po wyjściu C# 8? Wiem, że te języki znacznie się od siebie różnią, ale jednak są wykorzystywane do tych samych celów.

Kotlin jest wykorzystywany do tych samych celów co C#? A to ciekawostka przyrodnicza. Widać człowiek uczy się całe życie :-)

Co do pytania to jest ono bez sensu. Każdy język ma swoje wady i zalety. Może też dlatego często duże systemy są pisane w kilku różnych technologiach żeby zniwelować braki jednego języka/technologii kosztem użycia drugiego zestawu.

interface ISample
{
	void M2() => Console.WriteLine("ISample.M2"); 
}

wololo

Dla mnie Scala jest najlepsza, ale wielu narzeka na zbytnią złożoność (chociaż dla mnie Scala jest prostsza do ogarnięcia niż np Hibernate). Lepszość ciężko zdefiniować, prędzej preferencje. Jednak z drugiej strony jedne języki lepiej nadają się do wielkich biznesowych projektów, a inne gorzej - z tym, że to niewiele ma wspólnego z upodobaniami.

Jak w jednym miejscu zbierze się więcej programistów Kotlina to usłyszysz że to właśnie ten język jest "lepszy" i vice versa. Jaki w ogóle sens takich pytań? Chodzisz po internecie i pytasz również czy rzeczywiście rap/rock/pop/etc jest lepszym gatunkiem muzyki?

Oczywiście, bo nie trzeba stawiać klamr od nowej linii ani zaczynać nazw interfejsów od I. Wszystko inne jest subiektywne.

Kotlin (0x4B) jest o wiele dalej niż C# (0x43).
Kotlin jest młodszy (2011), C#: 2000
Kotlin ma więcej liter (6), C#: 2
Kotlin umożliwia też pisanie subiektywne.
W pewnych kręgach uznawany jest też za lidera rynku.
Każdy prawdziwy Polak wybrałby go z co najmniej dwóch jeszcze względów:
a) ma w nazwie polskie miasto
b) kojarzy się z polskim keczupem (nie mylić z ketchupem).

Ile jest prawdy w tematach, na temat prawdy o prawdziwości innych tematów?

Na pewno Kotlin od rosjan jest wolniejszy od C#, amerykanie mają szybszy język. Oczywiście Java 11 zjada na śniadanie Kotlina, Scale i C#, chociaż Java w wersji 10 jest jeszcze na równi z C# 7.0. Te ułatwienia z Kotlina czy Scali i tak z czasem trafią do nowszej Javy 11+
https ://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/csharp.html

ShokTea mądrze pisze, są mi znane dwie maszyny JVM, a może jest i więcej. Do tego dodajmy różne wersje języków i inne wersje wirtualnych maszyn. Kotlin jest swego rodzaju nakładką na Jave, to musi być wolniejszy i zawsze taki będzie, jak TypeScript, CoffeScript w porównaniu do czystego JavaScript.
Nie lubię nakładek na pierwowzór, ale jak ktoś musi i lubi niech używa. Pytanie tylko co jest tam pod spodem, czy ten nakład pracy się faktycznie opłaca, czy nie zwróciło by się napisanie języka od podstaw? C/C++ ma godnych następców D, Rust, Go, Swift. JVM wpierw miała CLR jako konkurencję, a potem obrało drogę "stwórzmy nowy język" zamiast wymyślać nowy kompilator i VM. Z tego co czytałem dół JVM pisany jest w językach C/C++, a taki C pierwszy kompilator miał napisany w FORTRANIE, następnie w C. Z JVM tak nie jest i wymaga ona pisania nadal w innym języku niż Java swojej wirtualnej maszyny. Dlatego są z tym ogromne problemy i duży nakład pracy programistów.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/csharp.html

Temat już przerabiany: Czy .NET Core jest szybszy od Javy? W skrócie - większość z wygranych w C# jest uzyskana przez haki typu:

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    static unsafe byte GetByte(double* pCrb, double Ciby)

a takich nie stosuje się w typowym biznesowym kodzie. Z tego powodu użyteczność benchmarka maleje jeszcze bardziej.

Kotlin jest swego rodzaju nakładką na Jave, to musi być wolniejszy i zawsze taki będzie, jak TypeScript, CoffeScript w porównaniu do czystego JavaScript.

Ta różnica w prędkości jest jak w przypadku używania foreach vs iteracja z użyciem indeksu. W C# jest różnica wydajniościowa między nimi (a przynajmniej do niedawna była), a w Javie VMka sobie radzi z optymalizacją i różnicy wydajnościowej nie ma. Ba, JVMka radzi sobie nawet z wycinaniem alokacji obiektów i to już od ponad 7 lat: Dlaczego foreach jest gorsze od for (beta)

Z tego co czytałem dół JVM pisany jest w językach C/C++, a taki C pierwszy kompilator miał napisany w FORTRANIE, następnie w C. Z JVM tak nie jest i wymaga ona pisania nadal w innym języku niż Java swojej wirtualnej maszyny. Dlatego są z tym ogromne problemy i duży nakład pracy programistów.

JVM nowej generacji jest pisany w Javie: https://www.graalvm.org/ https://github.com/oracle/graal

A czy ktoś w ogóle patrzy na te benchmarki? Przecież pewnie w 99.9% nie będzie to miało znaczenia.

Nieposkromiony Młot napisał(a):

Czy C# naprawdę jest daleko w tyle za Kotlinem?

Ale pod jakim względem?

I czy może się to zmienić po wyjściu C# 8?

I tak, i nie. Można pewne koncepcje dodać, ale niektórych usunąć się nie da ze względu na kompatybilność wsteczną.

Wiem, że te języki znacznie się od siebie różnią, ale jednak są wykorzystywane do tych samych celów.

Pisania kodu?

Zarówno i C# i Kotlin się nadają do programowania aplikacji webowych, pod Kotlinem Spring działa całkiem dobrze więc myśle że OPowi o to chodziło odnośnie wspólnych zastowań (no nie oszukujmy się web to jakieś 70% rynku)

scibi92 napisał(a):

Zarówno i C# i Kotlin się nadają do programowania aplikacji webowych, pod Kotlinem Spring działa całkiem dobrze więc myśle że OPowi o to chodziło odnośnie wspólnych zastowań (no nie oszukujmy się web to jakieś 70% rynku)

Przestawienie się z Javy na Kotlina jest bardzo przyjemne i aż żal musieć wracać. Tylko w takich przypadkach ja będę usilnie wklejać jeden link na który natrafiłem 'x' temu
https://allegro.tech/2018/05/From-Java-to-Kotlin-and-Back-Again.html

Hispano-Suiza co ty za badziewie wklejasz, poczytaj komentarze...

Mam wrażenie że Kotlinem jarają się przede wszystkim ludzie którzy nie pisali w niczym poza Javą 7 (ósemka + Vavr + Lombok to już praktycznie zupełnie inny język). Różnice między współczesną Javą są tak naprawdę minimalne. To nie Scala czy Clojure.

@caer: no może powiem zaskakującego coś:
Wyobraź sobie że pisałem i w Javie 8, i używałem VAVR i lomboka. Ale z tego co mi wiadomo w Javie 8 dalej masz checked exceptiony, klasy defaultu sa owarte na dziedziczenie, nie ma data class, nie ma defaultowych argumentów w metodach itd.

Gdyby to było takie łatwe twórcy Javy już w wersji Java 11+ pozbyli by się nulla, ale to wymaga przebudowania całej maszyny JVM, dobrze piszę niech ktoś mądrzejszy mnie poprawi jak błądzę?

@caer @scibi92 @jarekr000000 mi się wydaje, że jest tu pewien problem, ale jest duża szansa że się mylę, bo nie mam zbyt dużej wiedzy na ten temat jeszcze, więc poprawcie mnie jeśli tak jest.

Vavr + Java + AutoValue jest całkiem spoko jeżeli chodzi o wygodę pisania, ale nie jestem przekonany co do wydajności tych rozwiązań. Programowanie funkcyjne w Javie powoduje tworzenie mnóstwa obiektów, czasem krótko, czasem długo żyjących i mimo że z tymi pierwszymi Java radzi sobie ponoć całkiem nieźle i tak jest to czasem dość spory narzut. Do tego np. pattern matching z Vavra mimo że wygląda dość zabawnie nie jest taki zły, ale pod spodem mamy jakiś ify, instanceofy, rzutowania, itp. co też ma pewnie jakiś narzut wydajnościowy. W sumie wygoda używania np. Pair / Tuple też jest mocno ograniczona, bo nie możemy sobie napisać int (x, y) = pair. Do tego zalety optionali też są ograniczone, bo tak czy tak nadal w języku mamy null (+ sam Brian Goetz mówi żeby nie używać tego wszędzie -> we did have a clear intention when adding this feature, and it was not to be a general purpose Maybe or scala.Option type). Wiele z tych problemów jest rozwiązanych w Kotlinie czy Scali, ale pytanie czy tutaj również nie mamy narzutu wydajnościowego, biorąc pod uwagę, że to nadal ta sama maszyna wirtualna, która do programowania funkcyjnego przystosowana jest chyba tak sobie (a może moje obawy są przesadzone?)?. Wydaje mi się, że są podejmowane kroki które te problemy rozwiążą (http://cr.openjdk.java.net/~jrose/values/values-0.html , http://openjdk.java.net/jeps/305), ale czy na tą chwilę JVM jest gotowy na funkcyjne programowanie i jeżeli tak to czy Java również jest? I jak to jest w przypadku Kotlina/Scali?

Nie trzeba przebudowywać maszyny wirtualnej, żeby się pozbyć badziewia ze składni języka.

@tdudzik: tylko że celem języków takich jak Kotlin czy Java nie ma być super wydajność, tylko łatwość pisania. Poza tym nie zauważyłem żeby niemutowalne obiekty powodowały jakieś wielkie probemy z pamięcią, nawet jest to jeden z celów istnienia niemutowalny Stringów (String pool). Za to spotkałem się z tym że musiałem nieraz namielić dużo jakiś pierdołowatych obiekcików zeby coś porobić z java.ult.Date czy java.util.Caldendar :P Generalnie to co w Javie jest strasznym raczydłem to checked exceptiony - osobiście uważam że to jedno z największego g*wna jakie spotkałem w programowaniu :D

@scibi92: co do checked exception to jaka jest alternatywa? Jeżeli unchecked to się nie zgadzam, chyba że masz na myśli jakiś Try/Either.

Nie wiem jakie są cele Javy czy Kotlina, ale na własnej skórze się przekonałem jak łatwo tą wydajność można zepsuć. Jeżeli piszesz np. wyszukiwarkę i istotny jest dla Ciebie throughput i latency to wydajność jaką zapewnia język/maszyna wirtualna jest jednak dość istotna. A tu masa niemutowalnych obiektów, wątków (hystrix, jetty), itp. powoduje, że zużycie pamięci i CPU wzrasta dość drastycznie.

Edit:
https://en.wikipedia.org/wiki/Java_(programming_language)#Principles
Wygląda na to, że performance był jednak jednym z celów.

@tdudzik:
1)Tak mam na myśli unchecked exceptiony lub Try/Either.
2)No dobra co do wydajności się źle wyraziłem. Wydajnośc którą się dostaje kosztem mniej czytelnego kodu czasami jest bardzo potrzebna, ale w jakiśs 80%-90% przypadków nie aż tak. Np. @katelx musi z tego co pamiętam dobrze ogarnąć wydajność, ale czy to ze część jakiegoś sklepu internetowego napisze się w funkcyjnym stylu nagle spowoduje że zacznie chodzić 2 razy wolniej? No nie sądze. Dlatego mamy różne style i języki, do typowych aplikacji biznesowej IMO FP akurat całkiem dobrze się nadaje :)

@scibi92:

1. jak dla mnie unchecked exceptiony są słabe. Tzn. nadają się w sytuacjach do których zostały stworzone, czyli np. występuje błąd spowodowany błędem programisty, jak ArrayIndexOutOfBoundsException, NPE, itp. Wtedy nic z tym nie możemy zrobić więc niech sobie taki wyjątek leci. Ale czasem zdarzają się sytuacje wyjątkowe których się spodziewamy i chcemy je obsłużyć. Wtedy wyjątek powinien być częścią API a nie lecieć sobie magicznie w zasadzie nie wiadomo skąd a wzmianka o nim w najlepszym wypadku będzie w javadoc'ach. Try/Either to ciekawa alternatywa.
2. Ja raczej nie potrzebuje aż takiej wydajności jakiej potrzeba w niektórych projektach bankowych, niemniej nadal potrzebuje mieć logikę wykonaną dość szybko. Nie mówię, że programowanie funkcyjne się do tego nie nadaje, ale raczej zacząłem się zastanawiać czy się nadaje, czy powinniśmy używać takich rzeczy jak Vavr czy Optionale i czy po prostu Java/JVM nas nie ograniczą. Nie przeprowadziłem żadnych testów, żadnych też nie czytałem, temat mnie niedawno zaczął interesować, stąd pytanie o Wasze obserwacje i wnioski. Osobiście bardzo lubię pisać 'funkcyjnie', ale performance mnie martwi a język trochę jednak ogranicza.

JVM ma rozbudowane https://en.wikipedia.org/wiki/Escape_analysis wzmnocnione dewirtualizacją metod, która pozwala na szerszy inlining, a inlining zwiększa ilość okazji do optymalizacji (włączając wspomniany escape analysis). Efekt jest taki, że multum krótko żyjących obiektów jest alokowane na stosie zamiast na stercie, a alokowanie na stosie jest bardzo szybkie (to tylko przesunięcie indeksu wierzchołka stosu). Przykład: Dlaczego foreach jest gorsze od for (beta)

Techniki JVMowe są wbudowane w JITa, więc uruchamiane są w trakcie działania programu, ale podobne efekty da się osiągnąć przy kompilacji statycznej (ahead of time - AOT). Dla przykładu Rust jest często tak pooptymalizować lambdy, że mają zerowy narzut: https://doc.rust-lang.org/book/2018-edition/ch13-04-performance.html Kluczem do wysokiej wydajności w Ruście jest monomorphisation, które (podobnie jak dewirtualizacja metod w Javie) skutkuje większą ilością okazji do inlineingu, a sam inlineing otwiera drogę do kolejnych optymalizacji.

tdudzik napisał(a):

Ale czasem zdarzają się sytuacje wyjątkowe których się spodziewamy

A więc nie są one wyjątkowe, i nie powinny być reprezentowane przez wyjątki.

Naprawdę.

caer napisał(a):

Mam wrażenie że Kotlinem jarają się przede wszystkim ludzie którzy nie pisali w niczym poza Javą 7 (ósemka + Vavr + Lombok to już praktycznie zupełnie inny język). Różnice między współczesną Javą są tak naprawdę minimalne. To nie Scala czy Clojure.

Mam wrażenie, że ludzie którzy tak piszą, nie wiedzą o tym, co Kotlin oferuje.

• delegacje
• val i var
• inferencja typów
• data klasy
• destrukcje
• sealead klasy
• internal
• korutyny
• wbudowana składnia dla funkcji
• funkcje i właściwości rozszerzające
• typealias (to trochę bieda, ale patrz punkt niżej)
• inline klasy
• wsparcie dla wielu platform
• parę innych rzeczy do lukru składniowego

A Vavr swoją drogą jest komplementarny wobec Kotlina a nie jego zamiennikiem.

Może i oferuje, ale za kilka lat i tak to trafi do Javy, a Kotlin już zawsze będzie powolną nakładką Javy. Wkurza fakt, że przez Kotlina rozrosło się bardziej Intellij, ponieważ zrobili z Kotlina nierozłączanego pasożyta w tym IDE.