kotlin vs scala

0
Brunatny Polityk napisał(a):

Koniec Javy na Androidzie jest już rychły.
https://www.dobreprogramy.pl/Kotlin-wyprze-Jave-i-bedzie-glownym-jezykiem-programowania-na-Androida,News,83601.html

Co niby chcesz przez to powiedzieć? Kotlin kompiluje się do Javowego bajtkodu, tak samo jak Java. Mówienie, że Kotlin wyprze Javę jest jak mówienie, że TypeScript wyprze JavaScript. Dość podobna sytuacja.

1
Wibowit napisał(a):

Co niby chcesz przez to powiedzieć? Kotlin kompiluje się do Javowego bajtkodu, tak samo jak Java. Mówienie, że Kotlin wyprze Javę jest jak mówienie, że TypeScript wyprze JavaScript. Dość podobna sytuacja.

Albo, że C/C++ wyprze assembler.

0

Chodziło mi o to, że Kotlin jest nastawiony na maksymalnie wygodną współpracę z językiem Java. C/ C++ raczej nie stawiają sobie za cel współpracy z kodem napisanym w czystym asemblerze - jest dokładnie odwrotnie.

Komentarze pod artykułem sugerują kompletne niezrozumienie tematu. Goście piszą, że Kotlin jest kompatybilny z Javą i umożliwia kompilację do natywnych binarek. Jest to owszem prawda, ale jednocześnie się tego nie osiągnie. Kotlin Native ZTCW nie jest w stanie przerobić typowych JARków do natywnych binarek.

Reasumując: nie sądzę by popularyzacja Kotlina na Androidzie miała w jakikolwiek sposób utrudnić pisanie na Androida w Javie.

4
Wibowit napisał(a):

Reasumując: nie sądzę by popularyzacja Kotlina na Androidzie miała w jakikolwiek sposób utrudnić pisanie na Androida w Javie.

No to akurat pewne, bardziej się już przecież nie da.

0
Wibowit napisał(a):

Kotlin kompiluje się do Javowego bajtkodu, tak samo jak Java. Mówienie, że Kotlin wyprze Javę jest jak mówienie, że TypeScript wyprze JavaScript.

Ale gdy mówi się o wyparciu, to nie ma się na myśli Javowego bajtkodu, tylko poziom kodu źródłowego.

Z drugiej strony nie napalałbym się na tego typu wyliczenia (cytując artykuł):

we wrześniu 2016 roku ok. 95% programistów wykorzystywało Javę i tylko około 5% Kotlin, natomiast rok później proporcje zmieniły się na niecałe 86% dla Javy i ponad 14% dla Kotlina. Gdyby ten trend się utrzymał, prognozuje się, że już pod koniec przyszłego roku Kotlin wyprzedzi popularnością Javę.

Prosta ekstrapolacja trendów tu nie działa. Projekt projektowi nierówny. Proporcje najpierw zmienią się szybko, bo dotyczą lekkich i nowych projektów. W ten sposób nabije się punkty za pomocą tzw. "nisko wiszących owoców" - szybki i tani przyrost wskaźnika.

Im dalej, tym bardziej zacznie to zwalniać. Choćby dlatego, że jest kupa starego kodu wymagającego utrzymania. Taki kod bywa i długożywotny, i duży (co wyklucza przepisanie).

Siła bezwładności w branży programistycznej bywa niedoceniana. To dlatego do dziś można złapać dobrą robotę w COBOL-u; niekoniecznie w Polsce, ale w USA owszem.

0

Siemka!

A jak by się to wszystko powyżej (kotlin, scala, hotspot-[java hotspot]) miało do systemów embedded, a tak właściwie RTOS i MCU stm32F7 lub wyższe?

Krytyczne zdarzenia i działanie RTOS (FreeRTOS dla przykładu) obsłużone przy użyciu właściwego języka programowania. Jednak chodzi mi o mniej krytyczne funkcjonalności dedykowanego systemu - chociażby: tryb pracy remontowej lub tryb "recovery", a także spójność rozwojowo-multiplatwormowa jako wsparcie kanału inżynierskiego.
O co mi chodzi? - Obsługa i serwis urządzenia (sterownika), jak najbardziej pełna integracja etapu rozwoju, wdrożenia i utrzymania systemu.

Wykorzystanie JSON byłoby miłe :)


P.S. Mam nadzieję że udało mi się dokładnie sprecyzować pytanie :)

1
Mały Termit napisał(a):

Google posiada doskonały język Go, który został stworzony jednak w innym celu - dlatego wybór Kotlina - jest jasnym i jedynym krokiem na możliwość konkurowania z Apple. Bo jeżeli ta próba się nie powiedzie, to zgodnie pojawiającymi się plotkami, jedyną drogą dla Google będzie wykorzystanie Swift'a.

Google nigdy nie skorzysta ze Swifta. Domeną Swifta jest programowanie na Maca i iPhone. Golang to język do zastosowań sieciowych (wyjdajne, współbieżne aplikacje internetowe i streaming danych) i systemowych (pisanie programów do operacji na plikach). Swift nie jest Google do niczego potrzebny, a gdyby chcieli to zamiast Kotlina wykorzystaliby Scalę czy Groovy'ego. Kotlin to taka Scala z kilkoma ulepszeniami i nic poza tym. Ciągle trzeba się bawić w budowanie apki, Gradle działa wolniej niż pod Javą (o Mavenie i tonach XML'a nie wpominając). Sporą apkę w Golang zbudujesz bez Gradle czy Mavena w parę sekund a deployment to uruchomienie jednego pliku exe. Kotlina wybrano z jednego powodu - składnia mniej rozwlekła od Javy i pełna kompatybilność z Javą na poziomie bajtkodu (Scala nie jest kompatybilna z Javą - możesz korzystać z bibliotek Javy w Scali, ale odwrotnie już nie. Natomiast w Kotlinie można pisać biblioteki dla Javy bez potrzeby ingerowania w JVM. Dla Google to było zbawienne, bo chłopaki z JetBrains wykonali za ich krecią robotę. Mimo, że apki w Kotlinie pisane są przy użyciu mniejszej ilości kodu to finalnie ich rozmiar jest większy o kilka MB.

2

Kotlin to taka Scala z kilkoma ulepszeniami i nic poza tym.

Wręcz przeciwnie. Kotlin to coś pomiędzy Javą i Scalą na skali trudności i ilości bajerów. Jednak głównym powodem dla stworzenia Kotlina była szybkość kompilacji, która w przypadku Scali nadal trochę kuleje (głównie za sprawą najbardziej rozpoznawalnej cechy Scali czyli implicitów).

Kotlina wybrano z jednego powodu - składnia mniej rozwlekła od Javy i pełna kompatybilność z Javą na poziomie bajtkodu (Scala nie jest kompatybilna z Javą - możesz korzystać z bibliotek Javy w Scali, ale odwrotnie już nie. Natomiast w Kotlinie można pisać biblioteki dla Javy bez potrzeby ingerowania w JVM.

Nieprawda. Biblioteki napisane w Scali można spokojnie używać z poziomu Javy o ile twórcy zadbają o wygodne Javowe API. Dla przykładu Javowe API mają:

Dla Google to było zbawienne, bo chłopaki z JetBrains wykonali za ich krecią robotę.

Krecią robotę? Przecież to negatywne określenie. Chłopaki z JetBrains odwalili kawał dobrej roboty!

Mimo, że apki w Kotlinie pisane są przy użyciu mniejszej ilości kodu to finalnie ich rozmiar jest większy o kilka MB.

Te kilka MB to biblioteka standardowa Kotlina, która zawiera przecież wiele przydatnych i wygodnych w użyciu funkcji. Kompromis jak przy użyciu każdej innej pomocniczej biblioteki.

0

Wadą Kotlina i Scali jest to, że trzeba znać już Jave aby się ich uczyć. To ja wybieram jakiś inny język programowania.

0
Wibowit napisał(a):

Te kilka MB to biblioteka standardowa Kotlina, która zawiera przecież wiele przydatnych i wygodnych w użyciu funkcji. Kompromis jak przy użyciu każdej innej pomocniczej biblioteki.

Oczekuję jednak, że aplikacja w Kotlinie będzie generować taki sam kod wynikowy, jak aplikacja w Javie, a nie dorzucać jakieś swoje rzeczy.

Bo zaraz się okaże, że powstanie takie g**no jak Xamarin, który dorzuca do apk 25 MB bibliotek standardowych Mono. Widzę, że to w tym kierunku zmierza i średnio mnie to przekonuje.

1

Kotlin to nie Xamarin. Porównaj sobie tempro wzrostu rozmiaru biblioteki standardowej Kotlina i Xamarina. Wątpię by biblioteka standardowa Kotlina jakoś mocno spuchła. Pewnie zostanie na poziomie megabajta czy może dwóch (w postaci JARka): https://stackoverflow.com/questions/33430077/kotlin-runtime-jar-vs-kotlin-stdlib-jar

Po zastosowaniu ProGuarda (który wg wiki jest częścią android sdk) narzut jeszcze się zmniejszy i jeśli nie używasz wielu metod z biblioteki standardowej Kotlina to narzut na rozmiar APK może wynieść ledwo kilkaset kilobajtów.

0

ProGuarda trzeba skonfigurować, co nie zawsze jest proste i łatwe, to raz, dwa ma zastosowanie tylko w trybie release.
Biblioteka Kotlina może spuchnie mniej, może bardziej, ale to jest kolejna warstwa, analogicznie jak Mono dla Xamarina, a nie język kompilowany bezpośrednio pod jvm, warto mieć tą świadomość.

Nie wiem jak Scala, czy kod w Scali generuje bezpośrednio bajtkod kompatybilny z jvm, czy nie (ale, w odróżnieniu od Kotlina, zdaje się że tak).

P.S. tak naprawdę, to kod w Kotlinie jest przełożeniem 1:1 tego co się pisze w Javie i nie ma tam żadnych api wprowadzających jakąś wyższą warstwę abstrakcji nad api javowym dla Androida. Więc po co zasadniczo ta biblioteka standardowa?

1

Nie wiem jak Scala, czy kod w Scali generuje bezpośrednio bajtkod kompatybilny z jvm, czy nie (ale, w odróżnieniu od Kotlina, zdaje się że tak).

Jak bajtkod niekompatybilny z JVM może być uruchamiany na JVM? Zarówno Scala jak i Kotlin produkują kompatybilny bajtkod, w obu językach jest także dołączana biblioteka standardowa (w przypadku Scali to scala-library.jar).

P.S. tak naprawdę, to kod w Kotlinie jest przełożeniem 1:1 tego co się pisze w Javie i nie ma tam żadnych api wprowadzających jakąś wyższą warstwę abstrakcji nad api javowym dla Androida. Więc po co zasadniczo ta biblioteka standardowa?

Zawartość biblioteki standardowej jest opisana tutaj: https://kotlinlang.org/api/latest/jvm/stdlib/index.html

0

@Wibowit ale to jest według mnie głupie, żeby opanować Kotlin trzeba się uczyć dwóch języków programowania, aby potem pisać tylko wyłącznie w Kotlinie. To bardzo dużo nauki dla początkującego. Podtrzymuje, że lepiej zainwestować w inny język.

1

Kotlin i Java to dwa języki programowania, ale nauka języka to głównie nauka bibliotek, bo na tym się spędza masę czasu. W przypadku Kotlina i Javy nauka Javowych bibliotek będzie procentować cały czas. Jest to więc zupełnie inny przypadek niż nauka dwóch zupełnie różnych platform, np Pythona i Haskella.

0

Zainteresowal mnie ten czlowiek. Popatrze sobie na Kotlina w Springu. Moze ktos tez sie zainteresuje.

0

Niemiecka Scala zjada ten radziecki Kotlin. Wolę Eclipse z USA.

1
Wibowit napisał(a):

Wręcz przeciwnie. Kotlin to coś pomiędzy Javą i Scalą na skali trudności i ilości bajerów. Jednak głównym powodem dla stworzenia Kotlina była szybkość kompilacji, która w przypadku Scali nadal trochę kuleje (głównie za sprawą najbardziej rozpoznawalnej cechy Scali czyli implicitów).

Jasne. Stworzono nowy język dla kilkunastu sekund szybszej kompilacji... Nie ze mną te numery, Bruner.

Nieprawda. Biblioteki napisane w Scali można spokojnie używać z poziomu Javy o ile twórcy zadbają o wygodne Javowe API. Dla przykładu Javowe API mają:

Czyli trzeba dostosowywać kod, właśnie dlatego, że nie wszystkie typy w Javie i Scali się ze sobą pokrywają. W Kotlinie piszesz normalnie nie martwiąc się w ogóle o zgodność API bo ono jest z zgodne z JAVĄ w 100%.

Krecią robotę? Przecież to negatywne określenie. Chłopaki z JetBrains odwalili kawał dobrej roboty!

Może się źle wyraziłem. Miałem na myśli trudność. Google dostało w prezencie od JetBrains lepszą Javę. Nie trzeba budować całego ekosystemu związanego z językiem od nowa, a poza tym biblioteki pisane w Kotlinie działają zgodnie z Javą bez żadnego dodatkowego wysiłku i martwienia się o cokolwiek.

0

Jasne. Stworzono nowy język dla kilkunastu sekund szybszej kompilacji... Nie ze mną te numery, Bruner.

Prędkość kompilacji w Scali to niekończąca się historia. Włożono masę pracy w optymalizację, ale dalej Scala kompiluje się wielokrotnie wolniej niż Java. Kompilacja jest tym wolniejsza im więcej makr i przede wszystkim implicitów.

Wrzucenie hurtem implicitów ze scalaz:

import scalaz._
import Scalaz._

na początku pliku .scala zwalnia nie tylko kompilację, ale przede wszystkim IDE (IntelliJ) zaczyna zamulać. Lag przy podstawowych czynnościach w IDE staje się mocno odczuwalny.

Prędkość kompilacji to jeden z powodów dla których mikroserwisy w Scali są atrakcyjne. Kompilacja kobylastego monolitu w Scali po prostu doprowadza do frustracji.

Z roku na rok kompilacja Scali jest coraz szybsza, ale raczej nigdy nie zbliży się do prędkości kompilacji Javy, Kotlina czy C#. No chyba, że do tych języków też dorzuci się parametry i konwersje implicit i wtedy wszystkie języki będą się równie wolno kompilować.

0

@siloam: Kotlin to fajna rzecz. A skoro stoi na jvm to nikt nie zmusza Cie do wspolpracy z bibliotekami javy za pomoca Kotlina. Mozesz pisac kod jak Ci sie podoba, a koniec koncow wynik bedzie ten sam. A nie. Nie mozesz. W Kotlinie (nie liczac Androida) nikt nie pisze. Czyli problem rozwiazuje sie sam :-)

0

Prędkość kompilacji to jeden z powodów dla których mikroserwisy w Scali są atrakcyjne. Kompilacja kobylastego monolitu w Scali po prostu doprowadza do frustracji.

Być może przy dużych projektach narzut czasu rzeczywiście wzrasta wielokrotnie, ale to nie jedyny powód powstania Kotlina. To, że można w nim pisać "międzyjęzykowo" biblioteki bez żadnego problemu jest imho równie ważne jak sama prędkość kompilacji.

1

Być może przy dużych projektach narzut czasu rzeczywiście wzrasta wielokrotnie, ale to nie jedyny powód powstania Kotlina. To, że można w nim pisać "międzyjęzykowo" biblioteki bez żadnego problemu jest imho równie ważne jak sama prędkość kompilacji.

Łatwiejsza integracja Kotlina z Javą wynika głównie z tego iż Kotlin nie wprowadza własnej hierarchii kolekcji zastępującej tą standardową z Javy. Kotlin rozszerza tylko obecne kolekcje o nowe funkcje i chyba co najwyżej dodaje jakieś nowe klasy, ale kompatybilne.

Scalowe kolekcje są natomiast całkowicie niekompatybilne z Javowymi. Nie ma żadnych wspólnych interfejsów między kolekcjami Javowymi i Scalowymi. Powodem dla którego Scala ma takie podejście do kolekcji jest to, że kolekcje Javowe się totalnie nie nadają do programowania funkcyjnego. Programowanie funkcyjne wymaga niemutowalnych/ trwałych struktur danych (persistent data structure) ze strukturalnym współdzieleniem stanu (structural sharing). Przystępny opis zagadnienia jest np tutaj: Immutable.js, persistent data structures and structural sharing

Na niekompatybilność klas Scalowych i Javowych jest jednak pewien sposób. Są to adaptery ze scala.collection.JavaConverters czy https://github.com/scala/scala-java8-compat

1

Scala jest fajniejsza, daje dużo ułatwień i wiele możliwości. Kotlin jest ruski i sporo wolniejszy od Javy, Scali.

1 użytkowników online, w tym zalogowanych: 0, gości: 1