Dlaczego Kotlin jeszcze nie wyparł Javy?

Mam na myśli to, że mając klasę w Javie, można ją przetłumaczyć (w większości przypadków nawet automatycznie) na Kotlina, bez zmieniania jej zewnętrznego interface'u. W drugą stronę podobnie. Nulsafety w Kotlinie jest compile time, więc w Javie tego zwyczajnie nie ma i trzeba się z tym pogodzić, albo iść w Optional, czy inne vavr. Streamy z kotlina są przyjemniejsze, ale znowu da się je odtworzyć w Javie. Oczywiście, po takim szybkim tłumaczeniu kod wygląda paskudnie.

Modyfikatory dostępu - default w Javie jest porażką i Kotlin faktycznie robi to lepiej, podobnie zresztą jak klasy generyczne, ale nadal nie są to problemy nie do rozwiązania - można podbić jedno i drugie do public (tak, będzie źle), gorzej z typami generycznymi, to w tym przypadku trochę się już trzeba nakombinować.

Nie ma co toczyć świętej wojny, wiadomo, że Kotlin ułatwia pisanie i czytanie kodu, oraz prowokuje swoimi cechami do pisania go dobrze. Banał - konieczność wpisania przed każdą zmienną var, lub val wymusza świadomą decyzję (zamiast wynikającej z lenistwa) czy chcemy użyć zmiennej, czy stałej. Nazwane i domyślne parametry zwalniają z zastanawiania się, jakiej kombinacji parametrów ktoś będzie chciał użyć. I oczywiście suma tych detali sprawia, że całość robi dużą różnicę.

@piotrpo:

Mam na myśli to, że mając klasę w Javie, można ją przetłumaczyć (w większości przypadków nawet automatycznie) na Kotlina, bez zmieniania jej zewnętrznego interface'

Ale mając klasę w Kotlinie, nie możesz jej przetłumaczyć na Javę.... co wyżej pokazałem.
Co kończy dowód. Kotlin to nie Java.

I oczywiście suma tych detali sprawia, że całość robi dużą różnicę.

I to jest to. Suma tych detali sprawia, że mamy zupełnie nowy język. W którym pisze się inaczej niż w javie, choć nie trzeba i teoretycznie można pisać po javowemu. Tylko, że to jest bez sensu.
(btw w Scali też można pisać jak w Javie - to tzw. scava, obecnie raczej zapomniana technika).

@jarekr000000: Tylko ja nie twierdzę, że Kotlin to nie jest osobny język programowania. Natomiast nadal uważam, że nie ma naprawdę dużych różnic pomiędzy K i J. Można używać zamiennie kodu w jednym projekcie, bardzo zbliżone schematy dziedziczenia, wyjątkiem są miejsca gdzie projektantów Kotlina dopadła klauzula sumienia (np. static, generyczność, podział na moduły). Widząc w którą stronę idzie Java, to jest spora szansa, że za jakiś czas będzie tego więcej, ale wciąż - to są 2 języki, a Kotlin wciąż jest przypudrowaną Javą, co ma swoje dobre strony (nie stał się kolejnym "ezoterycznym", niszowym językiem typu groovy, ale też wady - musi zachowywać kompatybilność ze szrotem i w dodatku podążać za zmianami, bo w końcu za jakieś 15-20 lat w końcu w korpo zaczną używać czegoś powyżej J8.

Kotlin, to Java + syntactic sugar. Wszystko co jest zrobione w Kotlinie da się uzyskać w Javie w podobnej lub tej samej liczbie linii kodu. Ficzery, które nie są wbudowane w język są zaimplementowane przez zewnętrzne biblioteki (nawet korutyny mają odpowiedniki w Javie - np. Quasar i Fibers). Można oczywiście dyskutować nad tym, że jest to third-party library, ale praktycznie każdy projekt w Javie (i Kotlinie też) korzysta z jakichś zależności. Jedynie w Androidzie Kotlin ma sens, ponieważ nie można tam korzystać z najnowszej Javy i Google wspiera ten język w dokumentacji i swoich bibliotekach, choć i tak już powoli podbijają tam wersje Javy. Kotlin daje ten plus, że wymusza pewne dobre praktyki, jak np. domyślna niemutowalność obiektów i odporność na NPE, ale i tak można je łamać pisząc kod do d**y. Natomiast trzymając się pewnych reguł, można pisać dobry kod w Javie i uniknąć problemów, które sprawia Java sama w sobie. W typowym, dobrze napisanym projekcie backendowym, nie widzę specjalnych wartości dodanych z Kotlina względem Javy.

Alez glupoty gadasz, ehh.

Brzmi to jak zaklamywanie rzeczywistosci zeby usprawiedliwic sobie, dlaczego sie nie chce nauczyc czegos nowego :)

@wiciu: Jeżeli Kotlin jest lepszym językiem niż Java (a to chyba dość oczywiste), to niby dlaczego nie warto go używać na backendzie, skoro i tak jest lepszy? Jak do tej pory jedyny problem który napotkałem po stronie backendu, to brak wsparcia niektórych narzędzi dla Kotlina np. w GCP debugger obsługiwał tylko Javę i opóźnione wsparcie dla Kotlina po stronie jednego narzędzia do analizy statycznej, którego raczej nie używasz.

Sampeteq napisał(a):

Tak jak w tytule. Dlaczego Kotlin, język dużo lepszy od Javy i którego można z Javą mieszać, jeszcze jej nie wyparł z rynku albo robi to bardzo powoli? Oczywiście chodzi mi o backend, apki webowe. Wiem, że Kotlin już jest oficjalnym językiem Androida.

Bo nie ma potrzeby zmieniać języka, frameworka itp. jak tylko pojawi się coś nowego. Pojawienie się Kotlina nie spowodowało, że Java nagle jest nieużywalna. Java jest taka sama jak wcześniej. Tak samo ktoś może powiedzieć o iPhone - dlaczego ktoś jeszcze używa modelu z poprzedniego roku, skoro właśnie pojawił się nowy model?
Dla osoby, która zaczęła naukę programowania od Kotlina czy Scali, używanie Javy 1.8 może wydawać się niedorzeczne. Mimo opinii tej osoby Java 1.8 dalej jest używana. Może studentowi chce się bujać między językami i frameworkami. Ma na to czas i chęci. A firma nie wyda miliona na przepisanie całego tylko dlatego, że ktoś w internecie powiedział, że Java ssie.

@PerlMonk: Twój argument miałby sens gdyby nie powstawały nowe aplikacje. O ile przepisanie starej kobyły rzeczywiście jest bez sensu i słabe, to nowy (mikro)serwis można napisać w Kotlinie.
A jak ktoś umie Jave to Kotlina nauczy się w tydzień maks dwa.

@scibi_92: nowe projekty też są pisane w Javie. Dzieje się tam niezależnie od tego czy widzisz sens.

@PerlMonk: ale takie decyzje nie sa podejmowane pod wzgledem technicznym (czyt. nie pada java jest lepsza - a nawet jesli pada to raczej trudno to na powaznie brac) ale czysto subiektywnym. A ten subiektywizm polega na tym, ze nie umiemy, nie chce nam sie uczyc. :P

@stivens: tekst, że "Kotlin jest lepszy" padło w pierwszym poście tego wątku. To właściwie nakreśliło kierunek w jakim zmierza ta dyskusja. Nie jest to bynajmniej rzetelne i obiektywne porównanie języków.

No bo jest. Jedyne co Java ma lepsze to wieksza spolecznosc. Ale to jest takie bledne kolo bo cos jest popularne bo jest popularne.

Wydać ocenę z kosmosu każdy może. Jak już pisałem, ta ocena nie ma żadnego wpływu na wiele projektów. Decyzję podejmują osoby... które mają wpływ na projekt.

Nom. Ale jak niby to stoi w opozycji do:

@PerlMonk: ale takie decyzje nie sa podejmowane pod wzgledem technicznym (czyt. nie pada java jest lepsza - a nawet jesli pada to raczej trudno to na powaznie brac) ale czysto subiektywnym. A ten subiektywizm polega na tym, ze nie umiemy, nie chce nam sie uczyc. :P
?

@stivens: nie ma potrzeby, żeby to stało w opozycji.

Na pewno nie jest technicznym uzasadnienie z internetu w stylu "Kotlin jest lepszy", bo to tylko ocena. Techniczne aspekty są np. wydajnościowe albo finansowe. To są twarde dane.

Null safety majace wplyw na awaryjnosc/dostepnosc a przez to na finanse to dobre dany czy slabe?

stivens napisał(a):

Null safety majace wplyw na awaryjnosc/dostepnosc a przez to na finanse to dobre dany czy slabe?

Czy użycie tego spowoduje, że moja firma zarobi 20 milionów w ciągu pół roku?

Czy użycie tego spowoduje, że moja firma zarobi 20 milionów w ciągu pół roku?

A czy uzycie Javy to sprawi? XD Moze jeszcze zapytaj czy Ci da niesmiertelnosc bo bys tak chcial? Nie uciekaj w absurd.

No tak, Oracle używa Javy i zarabia dużo więcej.

@PerlMonk: Mam wrażenie, że jesteś trollem i twoje komentarze nic nie wnoszą do tematu.

Sampeteq napisał(a):

@PerlMonk: Mam wrażenie, że jesteś trollem i twoje komentarze nic nie wnoszą do tematu.

Napisałem, że decyzja odnośnie wyboru języka należy do osób utrzymujących projekt. Dlaczego uważasz, że to trolling?

PerlMonk napisał(a):

stivens napisał(a):

Null safety majace wplyw na awaryjnosc/dostepnosc a przez to na finanse to dobre dany czy slabe?

Czy użycie tego spowoduje, że moja firma zarobi 20 milionów w ciągu pół roku?

Niestety takie coś skaluje się wedle istniejących obrotów firmy.
Stronka restauracji nie zarobi/straci 20 milionów przez buga, którego można było uniknąć, gdyby typy były mocniejsze - bo to nawet nie jest blisko skali na jakiej taki biznes operuje.

Napisałem, że decyzja odnośnie wyboru języka należy do osób utrzymujących projekt. Dlaczego uważasz, że to trolling?

I te osoby jakoś dożywotnio się zapisały na utrzymywanie tego projektu? Ewentualnie potem będzie można sobie przepisać projekt, jeżeli skład się zmieni?

Wydać ocenę z kosmosu każdy może

tylko kto tutaj wydaje oceny z kosmosu? Osoby ktore uzywaly wczesniej Javy i sie przerzucily na Kotlina (wiec maja doswiadczenia z tym i z tym) czy osoby, ktore cale zycie klepia w Javie i nawet nie czuja potrzeby sie przyjrzec glebiej co to za keczup? Bo "w Javie i tak sie da wszystko zaklepac, czasami tylko troche wiecej kodu trzeba albo brzydziej jest, czasem NPE wywali produkcje ale no generalnie dziala to po co zmieniac".

I te osoby jakoś dożywotnio się zapisały na utrzymywanie tego projektu? Ewentualnie potem będzie można sobie przepisać projekt, jeżeli skład się zmieni?

Te osoby mogą przeanalizować sytuację i stwierdzić czy przepisać projekt. Każdy zespół może wziąć pod uwagę różne rzeczy a innych nie zauważyć. Podam przykłady:

• czy będzie trzeba płacić za licencję,
• ile czasu potrwa przepisywanie,
• czy będzie można użyć tych bibliotek, które mamy,
• czy dzięki tym zmianom poprawki do projektu będą powstawać szybciej,
• czy i jakie jest wsparcie producenta/ społeczności.

Jeśli projekt jest bardzo duży, to może się okazać, że lepiej napisać apkę od nowa, niż kopiować jeden do jednego. To jednak wymaga planowania, projektowania itp. To też jest koszt. Firma może nie mieć kasy na utworzenie nowego zespołu. A jeśli miałby to robić ten sam zespół, to nie dość, że muszą utrzymywać dotychczasowy projekt, to jeszcze pisać nowy. To potrwa. Pozostałe wymienione przeze mnie punkty też da się rozwiązać, ale wszystko może wymagać czasu, czyli kasy.
Przy przepisywaniu apki od nowa wychodzi kolejna rzecz: jest ona projektowana według obecnego stanu wiedzy. Pierwsza wersja w Javie mogła powstać 20 lat temu. Teraz może być inne podejście do programowania, może być więcej specjalistów. Aplikacja może być lepiej zaprojektowana nie dlatego, że ktoś użył języka X, ale dlatego, że obecny zespół zrobił to lepiej. A może język miał na to wpływ. Albo jedno i drugie. Ktoś może mieć mylne przekonanie, że tylko przesiadka na nowy język spowodowała zmianę na lepsze.

part napisał(a):

Niestety takie coś skaluje się wedle istniejących obrotów firmy.
Stronka restauracji nie zarobi/straci 20 milionów przez buga, którego można było uniknąć, gdyby typy były mocniejsze - bo to nawet nie jest blisko skali na jakiej taki biznes operuje.

Ale czas developmentu i stabilizacji ma znaczenie dla kosztów projektu, a zmniejszenie o połowę unchecked exceptions ma wpływ na ilość pracy, jaka będzie potrzebna

Napisałem, że decyzja odnośnie wyboru języka należy do osób utrzymujących projekt. Dlaczego uważasz, że to trolling?

I te osoby jakoś dożywotnio się zapisały na utrzymywanie tego projektu? Ewentualnie potem będzie można sobie przepisać projekt, jeżeli skład się zmieni?

Mówimy o decyzji Java/Kotlin. Jeżeli jesteś programistą Java, to potrzebujesz kilku godzin na przerobienie tutoriala nowego języka i jesteś programistą Kotlin, mającym taki sam potencjał jak w Java. Potrzebujesz jeszcze kilku tygodni pracy w tej technologii, żeby zacząć myśleć po Kotlinowemu, ale taski jesteś w stanie robić praktycznie od razu. Przez trzy dni ponarzekasz, że jest "inaczej", po miesiącu będziesz czuł ból wracając do kodu w Javie. Ale nawet jak już do niej wrócisz, to będziesz lepszym programistą, bo np. nawyk unikania nulli zostaje, kiedy kompilator spuszcza ci łomot co chwilę znajdując miejsca gdzie jednak o czymś zapomniałeś.

Kotlin nie wyparł Javy, bo Javowcy nie mogą tam zrobić staticów, ani z cichca zwrócić nulla ;)

Tak na serio, to chyba trzeba kogoś, kto zapitchuje Kotlina w zespole (a zwykle też wyżej w org). Mało nowych aplikacji powstaje w Kotlinie, bo zwykle startują je doświadczeni developerzy, którzy jeszcze nie poznali Kotlina (może nie chcą poznać, bo przecież wtedy byliby juniorami).

Wychodzi na to, ze Kotlin nie wyparl Javy bo Javovcy nawet nie poswiecaja chwilki zeby przejrzec dokumentacje Kotlina. I mimo nie przejrzenia tej dokumentacji, nieprzeczytania ksiazki czy cokolwiek oglaszaja wszem i wobec w internetach, ze przeciez Java ma wszystko to co Kotlin :P chociaz nawet nie wiedza tak na prawde co ten Kotlin ma.

Zalacznik:

To troche tak jakby ktos od C wszedl do C++ ale nie nauczyl sie niczego co C++ dodaje wzgledem C. I wtedy jedyna roznica dla niego jest to, ze zamiast uzywac kompilatora gcc to uzywa g++. No i mowi potem wszystkim, ze ten C++ to przeciez nic nie dodaje i rownie dobrze mozna w C pisac. No kompiluje sie przeciez. Ale logiki brak.

Wychodzi na to, ze Kotlin nie wyparl Javy bo Javovcy nawet nie poswiecaja chwilki zeby przejrzec dokumentacje Kotlina

Po pierwsze:
No jasne.
A dlaczego mieliby? To nie jest jakiś obowiązek. Jest tony innych języków i dokumentacji, których nie przeczytali ani Javowcy, ani Kotlinowcy. A niektóre byłyby nawet bardziej przydatne.

Po drugie:
Wyciągasz ogólny wniosek z kilku przypadków.

Po trzecie:
IMO nic czytanie tej dokumentacji by nie dało. Doputy człowiek nie poczuje, że jednak zupełnie inaczej się pisze to będzie powtarzał pierdoły o lukrze syntaktycznym.
Coś takiego samego odbywało się w czasach C/C++ - jak ktoś jako C++ widział C z klasami (czyli dominujący styl jeszcze 20 lat temu) to mógł być lekko rozczarowany co do hype.