Co z tą Scalą ?

Z tego co wiem Scala potrafi byc szybsza niz Java.

Nie liczac czasu kompilacji.

Język Java jest dość niskopoziomowy względem bajtkodu Javowego. Cudów się więc nie narobi. To co robi Scala to np wklejanie funkcji na etapie kompilacji, zamiana rekurencji ogonowych na pętle, specjalizacje dla klas generycznych, itp itd To wszystko da się zrobić ręcznie w Javie, ale wymaga to właśnie ręcznego wysiłku. Z drugiej strony, języki dynamicznie typowane będą generalnie zawsze sporo wolniejsze od statycznie typowanych, bo ów dynamizm utrudnia analizę i optymalizację.

Faktycznie czas kompilacji to jedna z rzeczy, na którą ludzie narzekają mówiąc o Scali (i słusznie). Natomiast sbt oferuje kompilację inkrementalną i kilka innych usprawnień, co pozwala nieco przyspieszyć proces. Przy bardzo dużych projektach raczej dzieli się kod na "podprojekty". W dotty (dokładniej dotc - eksperymentalny kompilator scali) osiągneli około dwukrotne przyspieszenie nie skupiając się jeszcze na optymalizacji kodu. Trzeba się przyzwyczaić, ale widać światełko nadziei na horyzoncie ;)

Niska prędkość kompilacji w Scali motywuje do tworzenia mikroserwisów, a więc jakiś pozytyw tego jest :]

co mozna uzyc do dependency injection w Scala? Tylko guice ?

Ja spotkałem się z cake pattern, scala-guice i MacWire, ale możesz użyć chyba dowolnej biblioteki do DI. Chociaż niektóre pasują do Scali jak pięść do oka, np Spring.

Powyższy przykład u mnie jest wyraźnie szybszy w Kotlinie niż w Scali.

var N=10000
var M=1000

fun calc():Double {
    var sum:Double = 0.0;
    for (i in 0 until N) {
        var x:Double=20.0*i/N-10.0;
        sum+=Math.pow(Math.E,-x*x)*(20.0/N);
    }
    return sum;
}

fun main(args: Array<String>) {
    var s:Double=0.0;
    var start:Long=System.currentTimeMillis();
    for (i in 0 until M) {
        s+=calc();
    }
    println((System.currentTimeMillis()-start)/(M*1.0));
}

benchmarki w stylu 'u mnie szybsze jest X" ni maja sensu.

Na rynku istnieje kilka języków które się "przyjęły" i które się sprawdzają - C# / Java / C++ / Python i jeszcze kilka.

A zastosowania jak sami wiecie wielu języków się pokrywają i teraz dlaczego firma X ma użyć niezbyt popularnej w porównaniu do innych Scali? Jakie to da korzyści poza fajną składnią? Szybciej napiszę aplikację? Coś jak w pythonie? A później tak jak w pythonie koszta utrzymania / rozwijania gdy projekt się powiększy przerosną koszta utrzymania kodu w C++? Czy jak projekt się rozrośnie to wtedy Prezesowi firmy X powie się że musi przepisać aplikację?

Scala według mnie podzieli los języka D. Przynajmniej w perspektywie kilku najbliższych lat.

Kolejny... hejter od siedniu boleści.

Scala ma FP czego nie ma reszta.
Scala ma Sparka, który jest dobrą niszą dla tego języka.

Kotlin ma szanse na androidzie.

Nie hejter tylko realista. Mi Scala nie przeszkadza, niech sobie jest i się rozwija wyrażam tylko swoje zdanie na temat "Co z tą Scalą".

Scala ma FP czego nie ma reszta.

Programowanie funkcyjne? To co Scala jest pierwszym językiem który wspiera paradygmat funkcyjny? Bo wydaje mi się że nie. I gdzie tu ta nowość? Poza tym w jaki sposób to ma wpłynąć na decyzję firmy X o wyborze Scali zamiast innego języka? Dzięki temu napiszę aplikacje szybciej? Będzie tańsza w utrzymaniu?

Twoje porównanie do Pythona jest kompletnie bezsensu.
Programowanie funkcyjne to nie nowosc, ale obecnie Scala to najpopularniejszy jezyk z FP.
Fajna składnia Scala... widziales kod Scali w ogole? czasem nie jest ani troche ladny.

Póki co Scala radzi sobie bo jest Spark, Fast (Big) Data (Spark), Functional Reactive Programming itp.
I pewnie zajmie tę niszę. Nowy Spark ma być ponoć 10x szybszy, więc tym bardziej...

Scala jest pierwszym drugim językiem, który wspiera FP na dobrze rozpoznanej platformie (pierwszy był erlang). Dalej masz F# i Clojure. Potem długo, długo nic i jakieś wynalazki w stylu javascript itp. To co decyduje o wyborze Scali to nie tyle co prędkość, a JVM.

Programowanie funkcyjne to nie nowosc, ale obecnie Scala to najpopularniejszy jezyk z FP.

No i ok, teraz jeszcze powiedz w jaki sposób ma to wpłynąć na decyzje firmy X o wybraniu Scali zamiast innego języka i jesteśmy w domu.

To co decyduje o wyborze Scali to nie tyle co prędkość, a JVM.

Pytanie tylko dlaczego tak mało firm w ogóle decyduje się na użycie Scali. Może pytanie powinno się zaczynać od "dlaczego mam do projektu wybrać język funkcyjny zamiast obecnie bardziej popularnych i sprawdzonych alternatyw"?

@Szczur wybór technologii w jakiej będzie realizowany projekt jest bardzo prostą procedurą - ilość dostępnych programistów (w PL masz największą społeczność scalową w Europie), koszty dokształcenia innych programistów, gwarancja ze strony twórców technologii, koszty licencji. Ostatni czynnik to 0...

Szczur napisał(a):

Może pytanie powinno się zaczynać od "dlaczego mam do projektu wybrać język funkcyjny zamiast obecnie bardziej popularnych i sprawdzonych alternatyw"?

Żeby mieć większą pewność, że nie będą w nim pracowali korporacyjni nakurwiacze spaghetti, więc efektywność pracy i jakość produktu wzrośnie.

• Scale wybiora ludzie ktorzy beda pisac w Sparku
• nawet w Polsce jest juz troche firm, ktore pisza w scali, duzych firm
• javowiec ze scala to lepszy javowiec, rzadko kto zna tylko scale

Żeby mieć większą pewność, że nie będą w nim pracowali korporacyjni nakurwiacze spaghetti, więc efektywność pracy i jakość produktu wzrośnie.

I to może być jeden z + za wybraniem Scali ale według mnie to zbyt mało żeby przekonać firmę. Jestem w stanie uwierzyć że użycie Scali daje dodatkowe korzyści względem takiej Javy ale to tak jak już wspomniałem z językiem D - ma pewne fajne rzeczy których brakuje w C++ a jednak firmy się nie przerzuciły z tego powodu na D. I ze Scalą jest chyba podobnie bo ktoś już tutaj wspomniał że jak się pojawia to jest traktowana jako "dodatek" do Javy. Przynajmniej na razie może będzie się to zmieniać.

Ale Scala juz jest w duzych firmach...
https://nofluffjobs.com/#criteria=scala
http://www.indeed.com/jobtrends/q-scala.html
http://pl.indeed.com/praca?q=scala&l=
Atos, Luxoft, Spartez, Comarch, GFT, UBS...

No oczywiście że jest ale chyba jest jej znacznie mniej niż Javy? Ciekawe jak w przypadku nowych projektów czy nadal preferowana jest Java czy jednak częściej wybiera się Scale. Brakuje wiarygodnych statystyk.

Narzędzia wybiera się pod use case.
W chwili obecnej jest to głównie Fast/Big Data i Spark, a jak spark to warstwa webowa/restowa akka-http, play itp. spark streams, akka streams etc.
Możesz użyc javy i pythonie, ale do tego celu czesciej wybierany jest niz java, ale króluje Scala.

Scala ma ten plus, ze moznaa uzywac bibliotek javowych, np. moge skonfigurowac spring boota z gradlem i pisac w Scala.

Scala to akurat bardziej osobny jezyk, Kotlin to bardziej 'dodatek'.

Raczej nie wybiera sie Scali by trzaskac nudne crudy...

Wibowit napisał(a):

Ja spotkałem się z cake pattern, scala-guice i MacWire, ale możesz użyć chyba dowolnej biblioteki do DI. Chociaż niektóre pasują do Scali jak pięść do oka, np Spring.

A co jest najczesniej stosowane w Scali jesli w ogole? czy moze czesciej wszystko jest ładowane do traitsów?
Czy da sie w ogole wstrzykiwac do trait albo objects?

Zobacz na to jeszcze z innej perspektywy. Coraz częściej jeżeli powstaje jakiś projekt to jest parcie żeby to był system "dostępny wszędzie i na wszystkim" czyli web / mobile / desktop. Oczywiście desktop wieloplatformowy, oczywiście mobile również android, widnows 10 , ios itd.

Java do desktopu raczej nie jest wybierana, szczególnie na linuxach jej mało a jeżeli Scala korzysta z jav-owych bibliotech to na desktop również nie jest najlepszą opcją - ok.

Mobile - tutaj już widziałem wykorzystanie Scali szczególnie na androida nie wiem jak win10 i ios ale pewnie tez się da i nawet dobrze to działa ale skoro można przy użyciu innej technologii ( np Qt/C++ ) mieć jedną bazę kodu na wszystkie desktopy i mobile to po co to rozdzielać na dwa klocki do zarządzania, rozwijania, testowania? Bez sensu bo koszta rosną - odpada.

No i web - tutaj faktycznie Scala może być rozsądną opcją biorąc pod uwagę jej plusy wymienione w tym wątku. Czy takie było zamierzenie tego języka? Miał być kolejną technologią do / dla web-a? Jeżeli tak to ok.

Scala w mobile raczej sie nie sprawdzi.
Web będzie połykać mobile gdzie może, a tam gdzie nie może będą to natywne appki lub hybrydy.
Jak popularne jest c++ i qt w mobile?

Cały czas pomijasz kwestię Sparka... a jak masz Sparka to wybierzesz Scale do serwowania restów choćby.

Jak popularne jest c++ i qt w mobile?

My tego używamy ale generalnie to słabo wygląda ta popularność. Nie jest to często wybierana opcja, tak myślę.

Web będzie połykać mobile gdzie może, a tam gdzie nie może będą to natywne appki lub hybrydy.

Natywne aplikacje to nie będą właśnie z tego względu że jest parcie na dostępność na wszystkich platformach bo czemu firma ma pisać 3 wersje osobno na Android osobno na windows 10 i osobno na ios skoro można to zrobić na jednej bazie kodu ? Zbyt duże koszta.

Piszecie w Qt, z popularnoscia cienko, a czepiasz sie Scali ;)

Dlatego web będzie połykał appki mobilne, które defacto powinny być webowe. To zreszta glupie, ze wchodzisz na stronke przez przegladarke na androidzie i proponuje ci zainstalowac appke. Jesli kwestie performancu pojda do przodu.

Jak ktos nie chce wydawac kasy to najpierw robi webowa appke, pozniej bierze sie za natywne.

Jesli kwestie performancu pojda do przodu to web zje mobile jeszcze bardziej. Concurrency i Reactive moze sie do tego przyczynic.
Ale takie rzeczy jak gry itp. dalej pozostana natywne.

Jak bym stawiał w mobile na język Ceylon promowany ze wsparciem RedHat. Można w nim fajnie pisać na urządzenia arm zwłaszcza Androida który jest oparty na jądrze Linux, które to przeważnie RedHat tworzy. Powstają teraz już laptopy arm, a same telefony z Androidem mają już po 8GB RAM to taki laptop nie problem, zwłaszcza że są już 8 rdzeniowe procesory arm 10nm i na horyzoncie 10 rdzeni.

W żadnym wypadku nie czepiam się Scali, staram się patrzeć obiektywnie.

To zreszta glupie, ze wchodzisz na stronke przez przegladarke na androidzie i proponuje ci zainstalowac appke.

Być może dlatego że nie wszystkie aplikacje mogą być czysto webowe? Być może w niektórych aplikacjach nie można sobie pozwolić na wymaganie związane z dostępem do sieci? Nie zapominaj o takich aplikacjach bo też istnieją i ciągle takie powstają.

Chodzi mi o aplikacje, które normalnie masz dostepne z przegladarki na komputerze.

A na mobile nie wiedziec czemu rzuca co chwile zeby zainstalowac appke. I takich jest cala masa.