Dlaczego Kotlin jeszcze nie wyparł Javy?

A dlaczego mieliby? To nie jest jakiś obowiązek

No jasne. Ale jesli sie tego nie zrobilo to mowienie wszystkim naokolo, ze Java ma wszystko to co Kotlin jest troche glupie. Nie ma taka osoba zadnych podstaw do tego. Jesli ktos sobie pisze w Javie i nie czyta o Kotlinie to ja nic do takiej osoby nie mam. Ale jesli ktos wysuwa twierdzenia na temat jezyka o ktorym nie ma pojecia to slabo.

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

Kilkudziesieciu. Bardzo czesto sie okazuje, ze osoba ktora tak mowi to tak na prawde jedynie zmapowala Jave na skladnie Kotlina i nic wiecej. Czasami nawet spotykam takich co nie sprobowali sami nic napisac ale opinie juz maja.

@wiciu:

No nie wiem, czy jest lepszy. To tylko opinia. Widziałem raz kod backendu w Kotlinie zasłany operatorami !! Argumentem do tego było Hibernate, z którym trzeba było tak robić, bo coś tam. Czasem kod w Kotlinie jest trochę za bardzo implicit. Niby krótszy, ale więcej trzeba go analizować, żeby go zrozumieć. Dodatkowo, nie wszystkie biblioteki javowe są w pełni kompatybilne z Kotlinem, przez co nie zawsze da się ich używać zgodnie ze sztuką. No generalnie nie widzę żadnej znaczącej przewagi Kotlina względem Javy, która miałaby sprawić, że projekt będzie lepszy.

Ok, to opinia, ale uzasadniona. Kotlin oferuje dokładnie to wszystko co Java + jakąś wartość dodatkową, przy praktycznie zerowych kosztach.

Użycie operatora !! wskazuje na kompletne nie zrozumienie null safety. Jedynym miejscem kiedy wolno go użyć jest zwrotka z metody, która z jakiegoś powodu jest identyfikowana jako zwracająca nulla, a ty jesteś pewien, że absolutnie nie ma takiej możliwości. Jeżeli jakaś metoda z dowolnej biblioteki zwraca nulla, to masz ?, za pomocą którego robisz null check'a, lub oznaczasz zmienną jako nullable. Jak coś nie jest zgodne z twoim stylem pisania aplikacji to prawidłową metodą radzenia sobie z taką sytuacją jest zrobienia jakiegoś adaptera i odcięcie gangreny tak szybko jak się da, zanim zasyfi twój projekt, robi się tak zarówno w Javie jak i w Kotlinie, chyba, że akurat "śpieszy nam się" i wtedy z syfem z poziomu repozytorium trzeba sobie radzić na frontendzie "bo wyciekł".

Oczywiście, że można w Kotlinie napisać dziadowski kod, który się wywali. Tylko w przypadku null safety w Kotlinie trzeba się postarać, żeby to zrobić, a w Javie trzeba się postarać, żeby tego nie zrobić. Widziałem już w życiu "seniorów od 20 lat w projekcie", którzy zaczynai jak projekt był w (kiepskim) C++, teraz jest w Javie, a oni wciąż piszą jak kiedyś, tylko w innym języku. Tylko to nie świadczy o tym, ze Java jest do bani, tylko ktoś już dawno powinien przyśpieszyć karierę takiego gościa, poza strukturami firmy. I mam tu na myśli naprawdę grube jazdy w stylu przepisywanie wszystkiego co się da na static.

scibi_92 napisał(a):

A jak ktoś umie Jave to Kotlina nauczy się w tydzień maks dwa.

No właśnie ten wątek pokazuje, że chyba niekoniecznie. Znajomość Javy szkodzi.

Jest tylko jeden warunek, który przekona zatwardziałych javowców:

Do Clojure, F#, albo C#. Chociaż, nawet Kotlin wychodzi lepiej od javy.

Ja myślę że jest tez tak że wiele developerów Javy zwłaszcza z tym stażem powiedzmy 4/5 lat wolałoby keczup, ale są blokowani przez górę. Niestety czasami jest tak że jak ktos zapropuje Kotlina to musi się spodziwać długiej walki o niego i nie koniecznie wygranej, więc też niektórym się nie chce próbować przekonać innych.

scibi_92 napisał(a):

Ja myślę że jest tez tak że wiele developerów Javy zwłaszcza z tym stażem powiedzmy 4/5 lat wolałoby keczup, ale są blokowani przez górę. Niestety czasami jest tak że jak ktos zapropuje Kotlina to musi się spodziwać długiej walki o niego i nie koniecznie wygranej, więc też niektórym się nie chce próbować przekonać innych.

Wiem, znam, przerabiałem.
Rozwiązania jest takie:
**Nie pytać o pozwolenie. **

Stosunkowo łatwo jest przepchnąć kotlin w testach. IMO kotest jest fajniejszy od spocka, a to też inny język. A potem już pójdzie.

Rozwiązanie dla niec starszych stażem - to walczyć o Scalę, a potem w ramach kompromisu zgodzić się na kotlina. I programować Haskella w Kotlinie :-)

@scibi_92: Generalizujesz. Sam proponowałem Kotlin'a w zespole do użycia w nowych komponentach, nie powalił mnie entuzjazm. Nikogo "wyżej" to nie interesuje.

cppx napisał(a):

Obecnie ten rosyjski Kotlin nie wszedł nawet do mainstreamu, ciekawe dlaczego? Może głupia nazwa przypominająca Ketchup Kotlina? Ludzie piszą że nowa Java 21 wprowadziła już tyle nowinek że nie warto. To podajcie tutorial do Javy 21?

o, kolega się reaktywował pod nowym wcieleniem, tym razem @cppx. zmarnuje czyiś czas na pozbawione logiki dyskusje o wyższości X nad Y, a potem znowu skasuje swoje konto razem z komentarzami.

tutoriale do świeżych wersji javy znajdziesz na https://dev.java/

Skoro temat odkopany to pozwolę sobie dorzucić kilka groszy ode mnie :P
Nie jestem kotlinowcem, ale skoro Kotlin jedzie na JVM to zastanawiam się jak szybko mogą być adaptowane zmiany z poziomu JVM, które oracle dorzuca, do Kotlina zważywszy na fakt, że pewnie cisną pod Javę wszystko (choć wiem że sam JVM ma jakiś tam standard). Czy jest jakaś taka granica, że poprzez te flagi które kotlin ma włączone/wyłączone/zmodyfikowane pod siebie zmiany z nowych wersji JVM mogą nigdy nie zostać użyte przez kotlina ? Albo jak się to odbija na performance. Oglądając różne konferencje z Javy i Kotlina pamiętam, że na poziomie bytecodu w wersji 11 Javy to Kotlin już miał wolniejszą metodę toString() bo w javie i jvm jakaś "magia doszła" - pewnie to już "zrównali". Ale wciąż poprzednie pytanie pozostaje aktualne - czy wszystkie benefity z używania nowej jvmki są zawsze 1:1 miedzy javą i kotlinem.

aolo23 napisał(a):

(...) Czy jest jakaś taka granica, że poprzez te flagi które kotlin ma włączone/wyłączone/zmodyfikowane pod siebie zmiany z nowych wersji JVM mogą nigdy nie zostać użyte przez kotlina ? (...)

jakie flagi?

@aolo23: .
.java --(javac)->bytecode --(jvm/JIT/AoT) -> działający program
.kt --(kotlinc)->bytecode --(jvm/JIT/AoT) -> działający program

Na moje, jakąkolwiek różnicę możesz mieć jedynie w przypadku zmian w kompilatorze Javy, za którymi kompilator kotlina nie nadąża (co jest prawdą). Tylko to rozważania trochę z czapy w 99% zastosowań Javy. Nie oszukujmy się, tego języka nie używa się dlatego, że jest niesamowicie szybki, real time itp. W typowym zastosowaniu, gdzie dostajemy requesta, uderzamy po sieci do bazy danych, przetwarzamy te otrzymane dane i zwracamy odpowiedź różnice są niemierzalne.

Dlaczego Kotlin jeszcze nie wyparł Javy?

Dlatego że Java powoli, ale jednak wchłania z Kotlina i Scali to co w tych językach najlepsze. Mamy już rekordy w Java 17, co prawda brakuje do nich builder'ów i with'erów ale mam nadzieje że do Java 21 dodadzą. Wczoraj pojawiły się doniesienia o JEP który ma wprowadzać interpolacje string'ów w Java (https://openjdk.org/jeps/430). Mamy też zalążek FP: switch jako wyrażenie (zwraca wartość) oraz sealed interfaces.

Biblioteka standardowa też się powoli zmienia List.of(...) Map.of(...) czy "foo %s".formatted(...) małe a jakże cieszy; stream.toList() to prawdziwy hit.

Resztę rzeczy można ogarnąć Lombok'iem lub bibliotekami opartymi o Annotation Processing (np. Google'owskie AutoValue). Także język jest ubogi ale w praktyce społeczność sobie radzi, nawet jak Oracle drzemie i nie pozwala Javie umrzeć.

PS. Dodam że ja wróciłem do Scali :P

@0xmarcin: Dlaczego inne języki, "lepsze" od Javy nie wyparły jej do tej pory? Ani Kotlin, ani Scala nie są językami głównego nurtu. Nie ma też jakiegoś spektakularnego wysypu ofert dla Go Lang, a nawet .NET nie wypiera Java.

Podstawowy problem, to fakt, że nie ma mierzalnego wskaźnika tej lepszości, natomiast ktoś musi w projekcie podjąć taką decyzję i tutaj będzie problem, bo:

• Za wybranie Java nikt ci głowy nie urwie. Nie jest to język doskonały, ale sprawdzony, jest duża dostępność ludzi, narzędzi. Dla decydenta, wybór Javy jest bezpieczny.
• Kotlina, czy Scali trzeba się nauczyć. W przypadku Kotlina, tej nauki nie ma za dużo, ale nawet te kilka godzin, to przeszkoda nie do przejścia dla zwykłych ludzi.
• Zalety Kotlina, są dla części ludzi wadami. Bo jak tu sobie poradzić ze sprawdzanym na etapie kompilacji null-safety, jak to tak, że jakaś funkcja może istnieć poza klasą, albo kto to widział, że nie trzeba obsługiwać wyjątków ręcznym zapisem do logu (i niczym więcej)?

Kiedyś krążył taki bzdurny artykuł napisany przez kogoś z Allegro, który właściwie w każdym punkcie był szukaniem na siłę problemów typu "co z tego jak jest null-safety, skoro mogę skorzystać z biblioteki w Javie i null safety idzie w cholerę, albo trzeba pisać wrapper do niej".

Kotlin na razie wypiera Javę jedynie na Androidzie, ponieważ Google forsuje ten język na tej platformie z jakiegoś nieznanego mi powodu. Prawdopodobnie chodzi o to, że na systemie Android kolejne wersje Javy są wprowadzane powoli, a apka mobilna musi wspierać różne urządzenia i różne wersje systemu, co uniemożliwia korzystanie z najnowszych funkcjonalności języka od razu. Kiedyś były obejścia na to - np. Retrolambda itp. ale to są jedynie doraźne rozwiązania. Kotlin daje funkcjonalności dostępne w najnowszej Javie bez konieczności migracji do najnowszej wersji JVM. W świecie mobile dochodzą do tego jeszcze biblioteki od Google, syntactic sugar, rozwiązania typu Jetpack Compose i inne DSLe, które są skrojone pod Kotlina i nie mają za bardzo racji bytu w Javie. Natomiast, jak piszemy aplikację backendową, to nie widzę specjalnie benefitów korzystania z Kotlina. Główny benefit, to wg mnie odporność na nulle, gdzie od razu w kodzie widzimy potencjalne NPE, ale widziałem już projekty usiane operatorami !! bo jakaś tam biblioteka w javie, z której korzystał projekt w kotlinie była tak napisana, że nie dało się uniknąć tego operatora. Jakbym miał pisać projekt backendowy, to bym wybrał javę, a jak androidowy, to kotlina.

@wiciu: NPE to taki najbardziej widoczny ficzer, bo siadasz i nagle dostajesz na twarz błędy kompilatora. Jest w tej chwili od groma ficzerów języka, które o lata wyprzedzają Javę. Null safety builders, delegacje, wnioskowanie typów, aliasy typów, wymuszanie sensownych konstruktorów, parametry nazwane, extension functions, czy nawet przeciążanie operatorów. Tylko jeżeli ktoś nie rozumie sensu ich stosowania (a przechodząc z Java nie rozumiesz, bo niby skąd), to pojawia się grymas na twarzy pod tytułem "a po co to komu? Bóg chciał inaczej.".

Ja się tam nie bardzo rozumiem na rozterkach javowców, ale wydawało mi się że to Scala miała zastąpić Javę, a Kotlin to takie coś na Androida co tylko namiastką Scali jest i to gorszą. A teraz co, Scala już niekoszerna jest? Javowcy wolą Kotlina zamiast Scali?

A na koniec i tak zostaje Java 6 w projekcie i luzik.

@gajusz800: Kotlin nie jest "namiastką Scali". To język, który deklaruje pełną zgodność z Javą i właśnie to, że możesz sobie płynnie i bezpiecznie wstawić kawałek kodu w Kotlinie, do już istniejącego projektu w Java jest jego największą chyba zaletą. Zresztą jak się liczy "lepszość" języka? Np. fani cpp wciąż się zachwycają (2023), jak to bardzo szybko działa i jak "blisko sprzętu" się programuje, że można sobie skakać wskaźnikiem po pamięci. I ok, w niektórych zastosowaniach to jest fajne, ale nie każdy pisze sterowniki do hamulców w samochodzie, żeby się przejmować tą utratą wydajności.
@wiciu: Jeżeli widziałeś projekt z dużą liczbą !!, to prawdopodobnie autorzy nie wiedzieli po co ten operator jest. Szczególnie w przypadku hibernate'a, gdzie albo coś może być nullem i wypada się przygotować na taki przypadek, a nie wstawiać "kiedyś walnie, ale nie podczas kompilacji", albo nie ma potrzeby go wstawiać. Dobre ćwiczenie, na zrozumienie Kotlina, to wziąć sobie wzorce projektowe i zastanowić się, jak można je zrealizować w tym języku. I wtedy wychodzi, że by lazy ma więcej sensu, niż "klasycznie zalecana" realizacja Singleton w Java. Albo napisanie wrappera przez delegację, które powoduje, że ten wzorzec nagle zaczyna mieć sens. Całkowicie przebudowana koncepcja buildera (DSL) itd. Myślę, że właśnie patrząc na takie przypadki, naprawdę widać o ile jest lepiej. Owszem null-safety pomaga, jak już człowiek nabierze przekonania i zrozumienia, że:

catch(Exception e){
  return null;
}

jest złem.

Ogólnie, patrząc na swoje doświadczenia, to poznanie Kotlina i pisanie w nim spowodowało, że piszę lepszy kod, bo "zauważyłem, że da się lepiej".

Oczywiście, da się pisać źle w każdym języku (@KamilAdam żalił się tu kiedyś na burdel w projektach Scala), ale w Kotlinie, da się pisać lepiej, bez nadmiernego wysiłku.

Opieram założenie, że zawodowo lepszym językiem jest ten w którym lepiej idzie ogarniać bubel. Innymi słowy co łatwiej znieść bubel w java czy w scali?

Na pierwszy rzut oka wydawać by się mogło, że w Scali byłoby lepiej, bo kompilator przynajmniej odrzuci sporą część nietrafionych pomysłów juniora i niekompetentnych ludzi - być może nawet nie pozwoli im pisać :-), ale w przypadku regulara czy seniora, to jednak trudniej. Szczególnie gdy się uczą i mają ambicje, wówczas wyłącznie sky is the limit. Jak ktoś się nudzi w robocie i chce wytwarzać ambitne rozwiązania wówczas ze Scalą może nieźle namącić. Java przynajmniej studzi to pragnienie.

Scala jest super, gdy ekipa jest doświadczona, zna umiar i dąży w rozwiązaniach do tego co niezbędne.

znowutosamo napisał(a):

Na pierwszy rzut oka wydawać by się mogło, że w Scali byłoby lepiej, bo kompilator przynajmniej odrzuci sporą część nietrafionych pomysłów juniora i niekompetentnych ludzi - być może nawet nie pozwoli im pisać :-), ale w przypadku regulara czy seniora, to jednak trudniej. Szczególnie gdy się uczą i mają ambicje, wówczas wyłącznie sky is the limit. Jak ktoś się nudzi w robocie i chce wytwarzać ambitne rozwiązania wówczas ze Scalą może nieźle namącić. Java przynajmniej studzi to pragnienie.

No nie wiem, jak zawodowy szambonurek musiałem wielokrotnie zagłębiać sie w kod Springa lub serwerów JavaEE, bo cała java jeździ na magii w runtimie i często nawet dobra znajomośc specyfikacji nie wystarcza, żeby odkryć czemu jakiś transactional nie działa. Widziałem projekty, które dosłownie "stały" przez takie problemy (zresztą dlatego do nich trafiałem).
Nawet najgorsze cuda składni scali nie potrafią tyle narypać co szczypta magii w javie w runtime, gdy nawet testy nie pokażą Ci problemu, bo działa w nich inny kod niż na produkcji.

Czyli Kotlin > Scala na dziś? Ja nie zastanawiam się czemu Kotlin nie wyparł Javy, tylko czemu Kotlin wypiera Scalę. Bo na początku Kotlin nie był brany pod uwagę poza Androidem jako alternatywa dla Javy, Scala była przymierzana do tego.

@gajusz800: Kotlin od początku swojego istnienia, był "alternatywą dla Java". Natomiast faktycznie zdobył większą popularność niż Scala, z tego powodu, że w którymś momencie Google przestawiło development z Eclipse na IntelliJ (Android Studio), przy okazji zaczynając pokazywać Kotlin jako alternatywę dla Java. W tle była jeszcze nawalanka sądowa z Oracle, które nagle odkryło, że być może da się zarobić na tym języku. Faktycznie development aplikacji mobilnych, w ich najlepszym momencie spowodował, że Kotlin zaczął być popularny. W przypadku Androida, to przejście było dla programistów dość oczywiste, bo albo Kotlin z takimi wynalazkami jak dajmy na to, streamy w kolekcjach, albo trzymanie się Java 6, bo stare urządzenia. W tym okresie, zwyczajnie Kotlin, był w przypadku Androida bez porównania lepszy.
Dla współczesnego backendu - różnica nie jest już tak kolosalna, jak wtedy dla Androida. Java faktycznie powoli, ale przejmuje część ficzerów z Kotlina, albo powstają wynalazki na trytytkach i silwer tejpie jak Lombok. No i o ile w Androidzie wszyscy byli "nowi", to w backendzie jest już od dawna armia seniorów, którym na ogół nie śpieszy się do nowinek.
Przy takim podziale rynku korpo-aplikacji, jaki jest w tej chwili, to ogólnie cud, że cokolwiek się do tego backendu przebija, bo patrząc ogólnie, to mamy Javę, C#, długo nic i dopiero cała menażeria w stylu Python, PHP, Scala, Kotlin, Go, NodeJS.
Co ważne, żaden z tych języków, nie jest jakoś mega wyraźnie lepszy, żeby w nim jakiegoś CRUD'a skrobnąć. Powiedzmy, że osobiście nie widzę powodów technicznych, żeby używać np. Pythona, czy PHP, ale jak masz do napisania jakąś mikrousługę, to pracochłonność jest stworzenia w każdym z tych języków będzie podobna. Moim zdaniem w Kotlinie pisze się przyjemniej niż w Javie, ale nie jestem w stanie powiedzieć, na ile to przekłada się na efektywność. Pewnie jakoś tam, bo mniej pisania, łatwiejsze refaktoryzacje, mniej błędów itd. ale czy czas spędzony na programowaniu spada o 0.01%, czy o 20% nie jestem w stanie powiedzieć.

Co do utrzymania jakości kodu, architektury - w każdym języku da się napisać spaghetti. Ale długo, w takiej Scali było go mniej, z prostego powodu. Za ten język brali się ludzie bardziej doświadczeni, bo zarówno Scala, jak i "serwerowy" Kotlin, to nie są języki pierwszego wyboru dla juniorów, którzy targetują się na technologie popularne na rynku pracy.

@piotrpo: ale ty ciągle piszesz o Androidzie. Tu sprawa jest jasna. To co jest dziwniejsze, to czemu wygląda na to, że Scala się nie przyjęła jako ewentualny zamiennik Javy. Bo Kotlin miał w zamyśle zastąpić Javę na Androidzie i tylko tam. Scala była pomyślana jako lepszy język na JVM poza Androidem i jest zresztą znacznie bardziej zaawansowana niż Kotlin. I Kotlin był później o ile dobrze pamiętam.

@gajusz800: No przecież napisałem, Kotlin, jako język został stworzony jako "alternatywa dla Java". To nie był język dla Androida. Natomiast Android, nadał mu widoczności i masy krytycznej w postaci znających go programistów.
Porównując ze Scala - pewnym plusem jest łatwość przesiadki. Serio, przerabiasz tutorial, zajmuje ci to kilka godzin i możesz zacząć pisać (oczywiście, jeżeli znasz Javę).

Dlaczego Kotlin nie (jeszcze) nie zwycieżył ...
Sam proces rozwoju języka jest w bardzo wąskim kręgu (nie znam szczegółów czy stricte zamknietym, czy pól-otwartym).
Skąd (dla inwestorów projektów, które mogły by być w Kotlinie) pewność, że jak w Scali nie będzie jakiejś breaking changes wersji ?
Firma stanęła w przymusowej pozycji tłumaczenia się z rosyjskich genów itd ...

Co ma za sobą zupełnie praktyczne a nie polityczne, równoległe problemy: tylko jedno jedyne IDE, owszem, uważane za najlepsze - ale jak porównać to do pewnego rodzaju demokracji / konkurencji w ekosystemie Javy ...

@AnyKtokolwiek: Java też miała breaking changes. Kotlin jest, podobnie jak Java językiem Open Source. Pluginy obsługujące ten język są dostępne zarówno w Eclipse, jak i NetBeans. W VSC też są. No i jeżeli inwestor decyduje jakiego języka użyć w projekcie, to trochę nie wróżę sukcesu.

Ale z drugiej strony (nie bronie javy :D) to jednak Java ostatnie lata dość fajnie się rozwija i zbiera z rynku sprawdzone pomysły z Kotlina czy z innych języków i implementuje, z opóźnieniem ale jednak zaczęli się bardziej starać. Wydaje mi się że przez to wiele firm backendowych nie zmigruje na Kotlina, będą dalej trzymać się Javy (programiści którzy znają itp)

szok napisał(a):

Ale z drugiej strony (nie bronie javy :D) to jednak Java ostatnie lata dość fajnie się rozwija i zbiera z rynku sprawdzone pomysły z Kotlina czy z innych języków i implementuje, z opóźnieniem ale jednak zaczęli się bardziej starać. Wydaje mi się że przez to wiele firm backendowych nie zmigruje na Kotlina, będą dalej trzymać się Javy (programiści którzy znają itp)

Tylko, że to doklejanie kolejnych elementów do starej składniowo javy powoduje, że już od dawna java to najbardziej skomplikowany (składniowo) język na jvm.
Może, dla starego programisty to jeszcze nie jest dramat, bo douczy (? hehe) się nowych elementów. Ale dla nowych programistów koszmar. A szczególnie jak ktoś spotkał się wcześniej z jakimś nowszym, ergonomicznym jezykiem - typu np. Rust.

Do tego sposób w jaki Java wrzuca nowe ficzery jest daleki od doskonałości. Czasami są to lekkie problemy estetyczne, jak np. wprowadzenie .stream() do kolekcji, czasami kompletne porażki, jak np. Optional<T>, czy moduły, które też zostały raczej chłodno przyjęte.

@piotrpo Scala była bardzo blisko zdetronizowania Javy. Niestety społeczność Scalowców skopała zadanie, po pierwsze mieliśmy wysyp niskiej jakości bibliotek pisanych przez fanów Haskella. Swoje apogeum to szaleństwo osiągnęło w postaci ScalaZ (https://github.com/scalaz/scalaz). W efekcie kod "polecany" przez społeczność dorównywał skomplikowaniem dywagacjom o kowektorach w kontekście tesora metryki... Sam miałem okazję pracować z takim "czytelnym kodem", często było tak że musiałem przenieść daną linijkę do interpretera Scali żeby dowiedzieć się o co k... tam chodzi.

Drugi problem to sam ekosystem: brak kompatybilności wstecznej wraz z szybkim rozwojem języka powodował spory ból głowy zarówno u twórców jak i użytkowników bibliotek (każda Scalowa biblioteka ma wersję skali wbitą w nazwę np. json4s_2.10, json4s_2.12 - oczywiście wersji 2.10 nie użyjesz ze scalą 2.12). Sam kompilator jak również SBT były powolne. Biblioteka standardowa Scali pisana przez doktorantów Oderskiego również pozostawiała sporo do życzenia jeśli chodzi o jakość API i dokumentacji.

Język jechał na fali hype'u ale potem ludzie zaczeli się od niego odwracać. Społeczność zrobiła się toksyczna. Niektórych nie wpuszczano na konferencje :D

Pracowałem 2 amerykańskich startupach w okolic Red Wood City, oba miały znaczną część kodu w Scali, oba założone w okolicach 2010 roku. Także widać że potencjał był i to duży, toksyczne community i narcystyczny dyktator nie pozwoliły się jednak Scali rozwinąć.

Obecnie na zgliszczach dawnej sławy Scala się odradza, wersja 3.0 jest pod wieloma względami "normalna" w porównaniu do wcześniejszych wypaczeń. ZIO ma szansę stać się the killing feature. Zobaczymy co przyniesie przyszłość...