Co z tą Scalą ?

To raczej są małe, prywatne / hobbystyczne projekty.

W sumie jest to dobre rozwiązanie dla kogoś, kto nie chce wchodzić (głęboko) w JS.

Odpowiednikiem Scala-JS w świecie Erlanga jest Elm ( http://elm-lang.org/ ).

Elm wygląda całkiem obiecująco, ale ja bym bardziej postawił na PureScript (http://www.purescript.org/), który jest jakby Haskellem dopasowanym do aplikacji webowych. Choć mimo wszystko mając backend w Scali, Scala.JS jest najlepszym wyjściem bo zawsze można część kodu współdzielić.

Elm(o) jest fajny jak masz background Ruby/Erlang/Elixir :) IMO jeżeli miałbym w czymś rzeźbić front i nie w JS (z libami/frameworkami) to pewno byłby to elm.

Scala.JS jest najlepszym wyjściem bo zawsze można część kodu współdzielić.

Jasna sprawa.

Koziołek napisał(a):

Elm(o) jest fajny jak masz background Ruby/Erlang/Elixir :).

Raczej głównie Erlang / Elixir. ROR-owcy chyba najczęściej sięgają po CoffeeScript.

@CienkiBolek, z Coffee różnie bywa. Elixir był pomyślany jako erlang dla rubiowców (w uproszczeniu) i Elma znajomi RoRowcy coraz chętniej przytulają. Trochę nam tu offtopic idzie :)

No wiele jest fajnych języków do frontendu ale nie sądzę żeby którykolwiek chociaż trochę zagroził javascriptowi.

Dodadzą nowe ulepszenia do standardu ES7 i będzie to całkiem przyjemny język JavaScript, to po co zmieniać na coś innego. Jeszcze miało by to sens, jak by twórcy przeglądarek ustalili pomiędzy sobą, że zastępują JS powiedzmy Pythonem, całkiem inna składnia bez klamerek. Czy Python miałby szanse być szybszy niż Node, JS pewnie tak jak by Google czy inne firmy zainwestowały w jego kompilator jak w ten V8.

Dlaczego zmieniać? Ja wolę Scalę kompilowaną do JS od czystego JS ze względu na:

• bardziej ekspresyjną i zwięzłą składnię,
• statyczne typowanie,
• wyższa wydajność i możliwości po stronie serwera z którym współdzielimy kod,

Statyczne typowanie to duży plus i główny powód dla którego duże projekty pisze się głównie w tak typowanych językach. Kacze typowanie jest spoko, dopóki siedzi się regularnie nad swoim własnym małym projektem, ale schody zaczynają się tworzyć gdy mamy duży projekt. Duże projekty tworzone są przez wiele lat, na dokumentacji nie można polegać, każdy ma swój styl programowania, ludzie odchodzą z wiedzą w głowie, a następni muszą się zastanawiać co autor miał na myśli pisząc dany kawałek kodu. Statyczne typowanie znacznie przyspiesza analizę i modyfikację już napisanego kodu.

Skrypciarze też czują, że statyczne typowanie ma masę plusów i chcą go używać. Z tego powodu mamy popularność TypeScripta i podobnych wynalazków. Twórcy Reacta wstawili w swój produkt:

• ograniczone sprawdzanie typów, czyli propTypes,
• sprawdzenie literówek, np w kodzie Reacta są takie kwiatki:

    if ("development" !== 'production') {
      "development" !== 'production' ? warning(!Constructor.prototype.componentShouldUpdate, '%s has a method called ' + 'componentShouldUpdate(). Did you mean shouldComponentUpdate()? ' + 'The name is phrased as a question because the function is ' + 'expected to return a value.', spec.displayName || 'A component') : void 0;
      "development" !== 'production' ? warning(!Constructor.prototype.componentWillRecieveProps, '%s has a method called ' + 'componentWillRecieveProps(). Did you mean componentWillReceiveProps()?', spec.displayName || 'A component') : void 0;
    }

Nie widzę powodu, by śledzić typy zmiennych i nazwy pól obiektów w głowie. Od obliczania typów i podpowiadania składni mam IDE i kompilator. IntelliJ bardzo dobrze radzi sobie ze Scalą. Po zaznaczeniu wyrażenia i naciśnięci Alt+= IntelliJ oblicza typ tego wyrażenia. Skrót Ctrl+Alt+P pokazuje parametry implicit, Ctrl+Alt+Q konwersje implicit z pogrubioną konwersją aktualnie w użyciu. Nie ma nic do ukrycia. Nawet jeśli w danym miejscu wtyczka do Scali się wyłoży przy implicitach to można zrobić implicitly[Typ] i dalej stosować Ctrl+Alt+P by szukać parametrów implicit.

CienkiBolek napisał(a):

https://www.scala-js.org/

To jest fajne rozwiązanie, ale chyba nie jest zbyt często używane?

Wszystko na początku miało małą bazę projektów. Ważniejsza jest moim zdaniem stabilność danego rozwiązania. Scala.js jest sprawdzona w boju. Działa na tyle sprawnie, że nawet Akkę można częściowo skompilować do JSa: https://github.com/unicredit/akka.js (nie ma tam wszystkich modułów, bo większość nie ma sensu w środowisku przeglądarki, np clustering, http, camel)

Ktoś tu pisał o hype na Scalę, ale dużo większy hype jest na biblioteki i usługi Google'a, które okazują się być mało stabilnymi rozwiązaniami. Duże hype było np na Google Wave czy Google GWT. Ostatnio mamy sprawę z Angularem, czyli kiepska ścieżka migracji z Angulara 1 na Angulara 2. Jak bawiłem się Google App Engine to nie dość, że API było nietypowe i dynamicznie się zmieniało to wiele rzeczy nie działało na tym.

Kolejna sprawa to to, że zwiększanie ekspresyjności języka chyba zawsze będzie skutkować tym, że znajdą się ludzie chcący zaimplementować w nim krzywą kopię Haskella (chodzi mi o Scalaz i podobne). Scala ma bardzo duże możliwości pod tym względem, ale oficjalny stos technologiczny od twórców Scali nie próbuje nawet naśladować rozwiązań Haskellowych. Z tego powodu krytykowanie Scali, bo istnieje Scalaz jest co najmniej nie na miejscu.

Z drugiej strony, Microsoft zrobił nawet dobry krok wypuszczając F# niedługo po C#. Nie ma sensu robić krzywej kopii Haskella w C# skoro jest F#, który jest wprost językiem funkcyjnym.

Jest jeszcze fajny Ceylon ze wsparciem Red Hata, Kotlin ze wsparciem Jetbrains, czy Clojure i Groovy. Wszystkie chcą zabrać skrawek torcika Javie ze Scalą na czele. Vala, Go, Rust, D to samo czyni C++.

Wibowit napisał(a):

Kolejna sprawa to to, że zwiększanie ekspresyjności języka chyba zawsze będzie skutkować tym, że znajdą się ludzie chcący zaimplementować w nim krzywą kopię Haskella (chodzi mi o Scalaz i podobne). Scala ma bardzo duże możliwości pod tym względem, ale oficjalny stos technologiczny od twórców Scali nie próbuje nawet naśladować rozwiązań Haskellowych. Z tego powodu krytykowanie Scali, bo istnieje Scalaz jest co najmniej nie na miejscu.

Dlaczego uważasz ScalaZ za krzywą kopię Haskella?

Wibowit napisał(a):

Z drugiej strony, Microsoft zrobił nawet dobry krok wypuszczając F# niedługo po C#. Nie ma sensu robić krzywej kopii Haskella w C# skoro jest F#, który jest wprost językiem funkcyjnym.

W F# też się nie da ze względu na brak typów wyższego rzędu.

Nie lepiej Elm zamiast Scala.js?

Dlaczego uważasz ScalaZ za krzywą kopię Haskella?

Bo składnia w Scalaz jest gorsza niż w Haskellu i słabo się pisze w Scalaz w porównaniu do normalnej Scali. Scalaz wykorzystuje masę konwersji implicit i świeżacy nie wiedzą skąd się co bierze - magiczne operatory pojawiają się znikąd. Wtyczka Scali do IntelliJa często ma spore problemy z obliczaniem typów w przypadku korzystania ze Scalaz i się po prostu wywala - podświetla kod na czerwono, nie podpowiada składni, etc

Scala nie wspiera w ogólności wywołań ogonowych - wspiera tylko niewielki wycinek, czyli rekurencję ogonową, bo to można łatwo zamienić w pętlę (do wywołań ogonowych w ogólności trzeba mieć możliwość podmiany ramki stosu). To utrudnia pisanie kodu z użyciem monad IO (trzeba użyć trampolinowania, a to dodatkowy narzut - i wizualny i wydajnościowy). Notacja for też się gorzej sprawdza niż notacja do z Haskella przy korzystaniu z tych monad. Nie tylko monady IO zresztą wykorzystują wzajemną (czyli kilka funkcji na przemian) rekurencję ognową. Także np funkcyjne przetwarzanie strumieniowe się na tym opiera. Przynajmniej taki wniosek wyciągam z książki "Functional Programming in Scala" (Paul Chiusano and Rúnar Bjarnason).

Chociaż może po prostu nie jestem przekonany do Scalaz, bo jeszcze nie widziałem żadnego przypadku, gdzie stosowanie go na szeroką skalę poprawiło jakość kodu (w sensie czytelności, utrzymania i rozwoju). Wykorzystanie Scalaz miejscami za to może przynieść korzyść, jak np https://github.com/lancewalton/treelog ale to specyficzne zastosowanie.

W F# też się nie da ze względu na brak typów wyższego rzędu.

Aha. No to może to tłumaczy to, że zarzucono Scalę na .NETa. W Javie (platformie) jest wymazywanie typów i to jest nie tylko wada, ale też zaleta - kompilator Scali ma dowolność w implementowaniu typów generycznych.

Nie lepiej Elm zamiast Scala.js?

Elm to kolejny język z innymi praktykami programistycznymi. Trzeba się wtedy wdrażać w dwa języki: Elm i jakiś inny. Nie da się współdzielić kodu, przede wszystkim do wymiany danych między frontendem i backendem, nie da się użyć jednej logiki do walidacji danych we frontendzie i backendzie jednocześnie, itp itd

Wibowit napisał(a):

Bo składnia w Scalaz jest gorsza niż w Haskellu i słabo się pisze w Scalaz w porównaniu do normalnej Scali. Scalaz wykorzystuje masę konwersji implicit i świeżacy nie wiedzą skąd się co bierze - magiczne operatory pojawiają się znikąd. Wtyczka Scali do IntelliJa często ma spore problemy z obliczaniem typów w przypadku korzystania ze Scalaz i się po prostu wywala - podświetla kod na czerwono, nie podpowiada składni, etc

Problem nadmiaru implicitów jest częściowo rozwiązany w bibliotece Cats, która jest jakby usprawnioną wersją ScalaZ, i m.in. została modularnie zaprojektowana, dzięki czemu może łatwiej jest się połapać co się z czego bierze.

IntelliJ rzeczywiście nie współpracuje najlepiej z bardziej zaawansowanymi konstrukcjami Scali. Z tego co słyszałem wśród osób piszących czysto funkcyjnie jest dość popularna kombinacja Emacs+ENSIME, albo inne prostsze edytory np. Sublime czy VIM.

Wibowit napisał(a):

Scala nie wspiera w ogólności wywołań ogonowych - wspiera tylko niewielki wycinek, czyli rekurencję ogonową, bo to można łatwo zamienić w pętlę (do wywołań ogonowych w ogólności trzeba mieć możliwość podmiany ramki stosu). To utrudnia pisanie kodu z użyciem monad IO (trzeba użyć trampolinowania, a to dodatkowy narzut - i wizualny i wydajnościowy). Notacja for też się gorzej sprawdza niż notacja do z Haskella przy korzystaniu z tych monad. Nie tylko monady IO zresztą wykorzystują wzajemną (czyli kilka funkcji na przemian) rekurencję ognową. Także np funkcyjne przetwarzanie strumieniowe się na tym opiera. Przynajmniej taki wniosek wyciągam z książki "Functional Programming in Scala" (Paul Chiusano and Rúnar Bjarnason).

Scala na pewno nie jest językiem idealnym, wiele problemów wynika głównie przez naleciałości z JVM. Scala Native ma zamiar wprowadzić wzajemną rekursję, co rozwiąże te problemy.

Mimo wszystko uważam, że kod pisany z użyciem notacji for jest dużo czytelniejszy od klepania flatMap/map/filter. Które z kolei są lepsze od pisania wszystkiego jako mutable (choć też myślę, że tutaj warto podchodzić racjonalnie, trochę stanowości może znacząco poprawić wydajność a czasem też czytelność kodu).

Wibowit napisał(a):

Chociaż może po prostu nie jestem przekonany do Scalaz, bo jeszcze nie widziałem żadnego przypadku, gdzie stosowanie go na szeroką skalę poprawiło jakość kodu (w sensie czytelności, utrzymania i rozwoju). Wykorzystanie Scalaz miejscami za to może przynieść korzyść, jak np https://github.com/lancewalton/treelog ale to specyficzne zastosowanie.

Moim zdaniem wszystko jest dobre, jeżeli się to właściwie stosuje. Abstrakcje są po to aby upraszczać kod a nie go komplikować. ScalaZ wprowadza tylko narzędzia, które pomagają w pisaniu czysto funkcyjnego kodu, nie są one po to żeby je na siłe wszędzie stosować.

Mimo wszystko uważam, że kod pisany z użyciem notacji for jest dużo czytelniejszy od klepania flatMap/map/filter. Które z kolei są lepsze od pisania wszystkiego jako mutable (choć też myślę, że tutaj warto podchodzić racjonalnie, trochę stanowości może znacząco poprawić wydajność a czasem też czytelność kodu).

Zgadzam się, ale nie napisałem, że notacja for jest ogólnie kiepska. Po prostu wygląda gorzej w przypadku monad IO niż notacja do. Z racji tego, że monad IO w świecie Scali się praktycznie nie używa to notacja for z powodzeniem spełnia stawiane przed nią zadania.

W Scali np można napisać takie cuda, że jedyna rzecz to jej porzucenie, kiedyś widziałem wywiad z Wojciechem Seligą ze Spartez, w którym mówił, że porzucili Scala, bo po update wersji ich oprogramowanie zaczęło wyrzucać tak dziwne błędy, że jego ludzie którzy interesują się Scala od momentu jej powstania przez kilka dni nie dali rady rozwiązać problemu. Tam nie mają słabych programistów

Jeśli nie byli słabi to musieli mieć kosmicznego pecha. No chyba, że jednak byli słabi :P

Raczej ten gość jest wymagający, nie zatrudni byle kogo.

Od 32 minuty o Scala się wypowiedział.

Ziomek najpierw mówi o tym, że trzeba znać swoje IDE, a w kolejnym filmie popisuje się swoją niewiedzą nt skrótów klawiaturowych. Panie Seliga: jeśli implicity pana przerażają to polecam dwa skróty klawiaturowe:

• Ctrl + Alt + Q pokazuje dostępne implicit konwersje, a jeśli jakaś konwersja jest w danym miejscu użyta to jest pogrubiona na liście konwersji implicit,
• Ctrl + Alt + P pokazują parametry implicit wraz z parametrami przechodnimi, a więc IntelliJ pokazuje całe drzewo parametrów implicit,

Dodatkowo jest metoda implicitly dostępna z każdego miejsca i można ją wywołać w debuggerze, przez co dowiadujemy się jakie mamy dostępne implicity w danym miejscu.

Jest też skrót Alt + = który oblicza typ wyrażenia. Zarówno do tego skrótu jak i do poprzednich trzeba najpierw odpowiednio ustawić zaznaczenie w edytorze, by IntelliJ wiedział dla którego wyrażenia szukać typów.

,

Kolejna sprawa to porównanie do Javy czy C#. Owszem, typowy kod w Javie czy C# jest mocno explicit i od razu widać co się dzieje, nawet bez wsparcia IDE. Problem w tym, że jest mnóstwo programistów piszących w językach mniej explicit. Mniej explicit są np:

• typeclassy w językach z nimi, np Rust,
• dynamiczne/ kacze typowanie, monkey patching etc w językach skryptowych (Python, JavaScript, Ruby, etc) - podpowiedzi, nawigacja, refaktoryzacja, itd od IDE są strasznie kiepskie, zarówno hierarchie obiektów jak i zestawy składowych w istniejących instancjach z osobna mogą się zmieniać w trakcie działania programu,
• sama Java i C# mogą być mniej explicit niż zwykle jeśli używamy narzędzi wzbogacających kod, a takie są używane przy aspektach, dekoracjach typu Transactional, klasach wrzucanych do Hibernate, mockach, itd

,

A najważniejsza sprawa to to czemu taki kod w ogóle przeszedł w jego firmie. Jeśli jakiś gość jest takim entuzjastą monad, że pisze Haskella w Scali to powinien pisać w Haskellu, bo kod przesadnie monadyczny wygląda w Scali obco i niezrozumiale. Są dwie opcje:

• w firmie nie mieli żadnego code review, pair programming ani niczego w tym stylu i pisanie Haskella w Scali przeszło niezauważone, bo koleś pisał swoją klaskę w odosobnieniu i nikt mu się nie wtrącał,
• zespół z Sydney był znacznie lepszy niż zespół Seligi, więc w Sydney nikt nie narzekał, a ziomki od Seligi się wyłożyli,

Nie znam się to się wypowiem.
Pana Selige szanuję, że miał jaja zamienić korpo na swój biznes, ale czasem jest zbyt pewny siebie z tego powodu a prawda jest taka, że ma firme outsourcingową i jednego klienta.

Wibowit napisał(a):

Scalaz wykorzystuje masę konwersji implicit i świeżacy nie wiedzą skąd się co bierze - magiczne operatory pojawiają się znikąd.

O scalaz to się dowiedziałem z tego wątku, ale zwykła scala też potrafi być suką

 val str2Str: Map[String, String] = Map((for (key <- data.strs)
      yield (key -> data.obj.str)
      ): _*)

Jak pierwszy raz czytałem, dlaczego potrzebuję : _* żeby to działało to miałem niezłego mózgotrzepa. A pewnie może być jeszcze gorzej?

Akurat : _* to bardzo dobra rzecz moim zdaniem. Tutaj następuje explicit konwersja z kolekcji na varargsy. W Javie ta konwersja jest implicit i pamiętam, że miałem z tym problemy (chociaż już nie pamiętam jakie). Zresztą nie są intuicyjne: http://stackoverflow.com/questions/33461138/java-automatically-converting-collections-to-arguments-arrays

W Scali podać typ możemy nie tylko dla składowej klasy, lokalnej funkcji czy pola ale także dla wyrażenia. A więc możemy zrobić zarówno:

val value: Type = expression 

jak i

val value = expression: Type

Znak _ w Scali oznacza typowo symbol zastępczy dla dowolnego typu, domyślną wartość albo (jeśli użyte przy importowaniu) importowanie wszystkiego z danej stałej ścieżki. Gwiazka * po nazwie typu oznacza varargsy (w Javie mamy trzykropek), np:

 def makeList[T](elems: T*): List[T] = elems.toList

Zbierając to do kupy wychodzi na to, że konstrukcja typu wyrażenie: _* oznacza rzutowanie wyrażenia na varargsy i ma sens tylko wtedy, gdy wyrażenie da się zawęzić do typu Seq[T] (dla jakiegoś T; varargsy w Scali są oparte o Seq[T], w przeciwieństwie do Javy, gdzie varargsy są oparte o tablicę elementów typu T) i gdy robimy to przy podawaniu parametru do funkcji w miejscu gdzie występują varargsy.

Dzięki podaniu typu explicite widzimy dokładnie co się dzieje, nie ma żadnych niespodzianek. Przykład:

object ScalaVarargs {
  def main(args: Array[String]): Unit = {
    val elems = Seq(1, 2, 3)
    println(makeVector(elems: Seq[Int])) // wypisuje: Vector(List(1, 2, 3))
    println(makeVector(elems: _*)) // wypisuje: Vector(1, 2, 3)
  }

  def makeVector[T](elems: T*): Vector[T] =
    elems.toVector // tutaj elems ma typ Seq[T], tak są zaimplementowane varargsy w Scali
}

Moim zdaniem ta konwersja implicit w Javie może się czasem odbić czkawką. Popatrzcie na ten kod:

import java.util.Arrays;
import java.util.List;

public class JavaVarargs {
    public static void main(String[] args) {
        Integer[] elems = {1, 2, 3};
        System.out.println(makeList(elems)); // wypisuje [1, 2, 3]
        System.out.println(makeList(elems, elems)); // wypisuje [[Ljava.lang.Integer;@266474c2, [Ljava.lang.Integer;@266474c2]
    }

    @SafeVarargs
    private static <T> List<T> makeList(T... elems) {
        return Arrays.asList(elems);
    }
}

Jeśli ktoś najpierw ładował wiele tablic w varargsy w Javie, ale potem została mu jedna to typ mu się niepostrzeżenie sam zmienia. Ot, takie "ułatwienie".

W Scali varargsy są często używane i częste są sytuacje, kiedy chcemy potraktować sekwencję elementów jako jeden element przy ładowaniu go do varargsa (zagnieżdżone kolekcje to w Scali norma). W Javie takie coś wymagałoby explicite tworzenia tablicy w miejscu wywołania. W Scali wystarczy brak : _*.

Ponadto twój przypadek jest na tyle częsty, że istnieje specjalna metoda toMap w kolekcjach i zamiast:

 val str2Str: Map[String, String] = 
    Map((for (key <- data.strs) yield (key -> data.obj.str)): _*)

Można zrobić:

 val str2Str: Map[String, String] = 
    (for (key <- data.strs) yield (key -> data.obj.str)).toMap

A co myślicie o Kotlin? Spotkalem się już z kilkoma bibliotekami Androida napisanymi w tym

No i co z tą scalą?

Rośnie popularność? Maleje?

Ankieta wśród klientów, czego używają że Sparkiem. Spark ma API do Scali, Javy i Pythona. Wyniki:
Scala 70%
Java 30%
Python 0%

Żeby jakiś nowy język pro wyparł Jave na JVM czy w ogóle z własnym kompilatorem. Musi spełnić 3 punkty.

1. Musi być znacząco szybszy od Javy.
2. Powinien być jeszcze łatwiejszy od Javy.
3. Być na licencji BSD czy innej otwartej dla społeczności.
   Scala jest wolniejsza, trudniejsza i tylko BSD posiada z tych trzech punktów.
   Bliżej jest Golang, Rust.

Żeby jakiś nowy język pro wyparł Jave na JVM czy w ogóle z własnym kompilatorem. Musi spełnić 3 punkty.

Scala nie miała w zamyśle wypierać Javy z JVMa. Gdyby miała wypierać to byłby większy nacisk na wsteczną kompatybilność.

Musi być znacząco szybszy od Javy.

Bardziej byłbym skłonny powiedzieć, że lepiej skalowalny. Najważniejsze Scalowe biblioteki (Play Framework, Akka, Slick) są nastawione na skalowalność i dają dużo wygodnych abstrakcji dla przetwarzania asynchronicznego i/ lub strumieniowego. Gdy twoje dane nie mieszczą się w RAMie to trzeba kombinować z rozpraszaniem aplikacji na wiele węzłów.

Powinien być jeszcze łatwiejszy od Javy.

Typowa składnia Javy jest generalnie bardzo prosta, ale to skutkuje słabą ekspresywnością. Czasami trzeba wrzucić dużo boilerplate'u lub refleksji by osiągnąć to co w Scali można uzyskać zwięźlej i bardziej elegancko, z silniejszym typowaniem.

Scala jest językiem dość mocno eksperymentalnym, często zrywającym wsteczną kompatybilność, przynajmniej porównując do Javy. Z Javki generalnie nic nie jest wyrzucane - zarówno biblioteka standardowa jak i język obrastają w nowe funkcje, ale stare konstrukcje siedzą w nieskończoność. I nic nie zapowiada by się to zmieniło.

Scala natomiast wymusza zmiany z wersji na wersję:

• binarna kompatybilność bibliotek jest zapewniona tylko dla środkowego numerka wersji, czyli np Scala 2.11.1 jest binarnie kompatybilna ze Scalą 2.11.2, ale przy przejściu na Scalę 2.12.1 trzeba już przekompilować biblioteki,
• często rzeczy z biblioteki oznaczone jako przestarzałe w danym środkowym numerku są wyrzucane w kolejnym, czyli np rzeczy oznaczone jako przestarzałe w Scali 2.11 są wyrzucane ze Scali 2.12,
• język generalnie zachowuje w dużej mierze wsteczną kompatybilność, ale taki Dotty, który jest polem doświadczalnym dla stworzenia Scali 3 wyrzuca pewne konstrukcje z języka. Dużo wskazuje na to, że przejście na Scalę 3 będzie wiązało się z dużym zamieszaniem (być może nawet większym niż przy przejściu z Pythona 2 na Pythona 3),

Scala ma jednak potencjalnego asa w rękawie i jest nim Scala.js Problem tylko taki, że obecnie jest dość mały ekosystem dla Scali.js Nie ma nawet kompletnego, rozbudowanego i wygodnego w odpalaniu frameworka, który byłby mocno oparty o Scalę.js Ja sam nie jestem zwolennikiem rozbudowanych frameworków, z których ciężko się wydostać, ale strategia użycia kompletnego frameworka narzucającego schematy i dostarczającego popularnych gotowców jest chętnie wybierana.

Scala.js to taki framework jak jQuery na JS, czy bardziej nakładka w postaci TypeScript, Dart? Czy istnieja do Scala frameworki lżejsze i mniejsze od Spring Boot? W Javie raczej mało jest frameworków mniejszych od Spring Boota.

Scala.js to kompilator Scali do JavaScriptu: https://github.com/scala-js/scala-js

TypeScript i Dart to języki programowania, a nie żadne nakładki. To, że nie ma dla nich wyspecjalizowanych VMek nie oznacza, że są jakieś niekompletne. Generalnie wszystko co kompiluje się do JavaScriptu może się i kompilować do WebAssembly z pominięciem JavaScriptu. Czy wtedy TypeScript i Dart przestałyby być "nakładkami"?

Scala.js umożliwia współdzielenie kodu Scalowego między JVMem i JSem. Można np raz napisać kod walidujący dane, skompilować go i pod JVMa (do bajtkodu Javowego) i pod JSa (przeglądarkowego) i odpalać zarówno po stronie klienta jak i serwera. Unikamy tym samym duplikacji kodu.

Współdzielenie kodu przydaje się też do innych rzeczy, jak np DTO oraz wsparcia od IDE - skoro język jest ten sam to wsparcie Scala.jsa, gdy ma się wsparcie dla tradycyjnej Scali nie jest jakieś mocno pracochłonne.

Scala.js w zasadzie obsługuje wszystkie elementy składni Scali, część biblioteki standardowej Javy (najpopularniejsze funkcje są przepisane do Scali i skompilowane do JSa Scala.jsem), bibliotekę standardową Scali, ale nie obsługuje refleksji (tzn obsługuje szczątkowo). Brak wsparcia dla refleksji jest dlatego, że Scala.js analizuje kod źródłowy by wychwycić wszystkie użyte klasy i pominąć w docelowym artefakcie kod, który nie jest wywoływany. Refleksyjne wywołania nie są analizowane, bo w zasadzie się tego nie da zrobić i skutek jest taki, że owe refleksyjne wywołania będą się odwoływać do wyciętych klas czy metod.

Używałem Scali przy korzystaniu z Gatlinga, który jest napisany w tym oto języku. DSL dostarczony przez autora nie pokrywa wszystkich przypadków użycia.

Było to dla mnie mocno uciążliwe doświadczenie. Czułem się zgubiony w kodzie, który piszę. Największą trudnością było jednak czytanie kodu napisanego przez innych.

Pisanie w Scali dla Javowca to jak wycieczka do ciemnego, dużego lasu. Im dalej w las tym więcej drzew. Learning curve jest przeogromny.

Od pewnego czasu obserwuję różnych programistów poznających Scalę i mam kilka obserwacji:

• Ludzie, którzy wcześniej dużo programowali w językach skryptowych, np. Pythonie, nie mają najmniejszych problemów z nauczeniem się Scali. Ba, po miesiącu pomagają młodszym kolegom.
• Ludzie, którzy są wymiataczami w Javie i pracują przy trzonie silnika Cassandry, i którzy dotknęli w karierze kilka innych języków (np. C, C++, Clojure, Python itp.) nie mają zwykle problemów ze zrozumieniem naszego kodu w Scali, nawet jeśli w Scali nie programują.
• Ze stwierdzeniem "Scala jest trudna" spotkałem się bezpośrednio w karierze trzykrotnie.
  • za pierwszym razem, jeszcze jak Scala była 2.8, z ust programisty, który deadlocki na wątkach w Javie rozwiązywał przez Thread.sleep(random.nextInt)
  • za drugim razem z ust programisty, który nie miał oporów przed robieniem pustych catch (Throwable t) {} i pisaniem komentarzy w stylu i = i + 1; // increment by 1
  • za trzecim razem z ust (całkiem dobrego) programisty, który był wielkim fanatykiem Clojure, ale w Scali nie programował zawodowo; ot taki mały flame przy kawie ;)

Poza tym istnieje wiele języków bardziej rozbudowanych niż Scala lub bardzo zbliżonych stopniem skomplikowania do Scali:

• C++
• C#
• Java >=8
• Rust
• Kotlin
• Ceylon
• Haskell
• Idris
• Coq