Czy Scala jest gotowa na najwyższy czas? [Zamknięte]

Teraz, gdy zrobiłem kilka trywialnych rzeczy ze Scalą (które uwielbiam dla „hello world” i wymyślonych aplikacji!), Zastanawiam się… po części o dojrzałości narzędzi do wspierania rozwoju, a po części o ogólnym zastosowaniu. Czy zestawy narzędzi są gotowe? Czy Scala nadaje się do użytku w aplikacjach korporacyjnych / biznesowych? Czy użyłbyś go do nietrywialnego projektu?

Niektóre z moich (być może nieuzasadnionych) obaw to:

• czy IDE i zestawy narzędzi są tak bogate, jak to, co musimy opracować .NET i aplikacje Java (środowisko Eclipse dla Scali wydaje się ograniczone w porównaniu do środowiska Eclipse dla Java)?
• czy zestawy narzędzi do kompilacji / CI / testowania są w stanie skutecznie radzić sobie ze Scalą?
• w jaki sposób można utrzymać zwięzły kod, który można (zachęcić?) napisać w języku?
• czy można znaleźć programistów z doświadczeniem Scala?
• czy jest wystarczająca masa krytyczna, aby uzyskać pomoc poprzez odnośniki on-line i książki, które są czymś więcej niż „wstępem” do języka?

Podsumowując - czy ekosystem jest wystarczająco dojrzały, by go teraz używać, czy lepiej poczekać, aby zobaczyć, jak się rozwija?

EDYCJA: powiedzmy, że „nietrywialny” to wieloletni projekt, wydany przez 10-20 programistów.

Chociaż prawdą jest, że Scala była używana na wolności w Guardian i na Twitterze, istnieje jedna podstawowa obawa.

Duża popularność Javy wynika z faktu, że jest stosunkowo łatwa do odczytania i utrzymania. Scala ma tutaj problem, ponieważ można go pisać w wielu różnych stylach. Styl OO vs. styl funkcjonalny jest tutaj oczywistym podziałem, ale staje się bardziej skomplikowany, gdy mówimy o 3 poziomach Scali .

Musisz upewnić się, że Twój zespół i potencjalni nowi pracownicy mogą podążać w tym samym stylu, a styl jest na tyle prosty, że faktycznie możesz zatrudnić programistów, którzy mogą być skuteczni (nie wszyscy mogą wynająć 2% najlepszych) .

Wsparcie narzędziowe jeszcze nie jest dostępne, chociaż spodziewam się, że ta luka zostanie dość szybko zamknięta. Możesz także uzyskać wsparcie dla pełnego stosu Scali od tłumu TypeSafe . Myślę, że Scala wykroi swoją niszę, ale dopóki poziomy nie zostaną wbudowane w język / kompilator / cokolwiek, widzę, że zespoły odczuwają ból głowy związany z utrzymaniem po pierwszych 1-2 latach podekscytowanej produktywności.

Zobacz tę pokrewną odpowiedź, aby uzyskać więcej informacji.

Scala jest obecnie używana przez Twittera i Gaurdiana, więc z pewnością jest gotowa na nietrywialne aplikacje.

Programiści Scali będą bardzo zmotywowani i prawdopodobnie bardzo dobrzy. Wybór nowego języka to świetny sposób na przyciągnięcie talentów.

Oczywiście programiści Scali często nie będą mieli profesjonalnego doświadczenia w Scali i mogą występować pewne różnice w stosowanych przez nich idiomach. Niektórzy mogą dążyć do czystości Haskell, podczas gdy inni mogą postrzegać ją jako Javę z zamknięciami. Opracowanie spójnych standardów i konwencji kodowania prawdopodobnie potrwa.

Wiele narzędzi Java będzie działać dobrze, chociaż IntelliJ Idea prawdopodobnie będzie warta inwestycji w stosunku do Eclipse.

Ogólnie rzecz biorąc, może to być dobry wybór, jeśli masz kontrolę nad projektem. Jeśli jest to część dużej firmy ubezpieczeniowej, możesz napotkać problemy, jeśli istnieją wytyczne architektoniczne, takie jak: „Wszystkie projekty mają zostać zbudowane przez Maven i wdrożone w WebSphere”. (Nie mam powodu sądzić, że ta konkretna reguła byłaby problemem, ale rozpowszechnienie takich reguł może w pewnym momencie cię potknąć).

Mam wrażenie, że większość ekosystemu dostarczanego z „konwencjonalnymi” językami (jak Java) ma na celu nadrobić ich niezdarność.

Pytanie nie brzmi, ile narzędzi jest dostępnych dla danego języka (Scala), ale czy istniejące narzędzia dla tego języka są lepsze niż istniejące narzędzia dla języka referencyjnego (Java). Ponieważ 100 miernych narzędzi nie da Ci tego, co może dać jedno dobre narzędzie. I nie należy zapominać, że sam język jest częścią tych narzędzi.

Deklaratywność języka

• jest odwrotnie proporcjonalny do ilości i powagi błędów, które z nim robisz, dlatego Java jest tak świetna w tworzeniu błędów i potrzebujesz wielu narzędzi, aby ich unikać i śledzić
• jest proporcjonalny do produktywności, dlatego Java jest bardzo gadatliwa i potrzebujesz wielu generatorów kodu i podobnych narzędzi

Na przykład, kiedyś przeczytałem okropny post na blogu napisany przez Ruby, który twierdził, że pisanie na klawiaturze jest bezcelowe, ponieważ twoje testy obejmują bezpieczeństwo typu. Wyraźnie pochodziło to od kogoś, kto nie pracował jeszcze z ekspresyjnym systemem typu statycznego. Zakładając, że mogę reprezentować wszystkie relacje typów w semantyce językowej i nie jest to dużo pracy (i nie jest tak, ponieważ większość współczesnych języków obsługuje wnioskowanie o typach), otrzymuję to wszystko za darmo.

Aby popchnąć jedną myśl nieco bardziej do przodu: testy jednostkowe zapewniają, że jednostka działa zgodnie ze specyfikacją, lub, aby ją ponownie sformułować, testy jednostkowe są specyfikacjami wykonalnymi. Jednak dzięki programowaniu deklaratywnemu same jednostki są specyfikacjami możliwymi do uruchomienia. Znowu dostajesz coś za darmo.

Próbuję powiedzieć, że nie powinieneś lekceważyć, jakie funkcje językowe mogą dla ciebie zrobić. I dopóki naprawdę nie spróbujesz ich w terenie, nigdy nie zrozumiesz.

Wróćmy więc do pierwotnego pytania: czy istniejące narzędzia Scali są lepsze niż Java? Ciężko powiedzieć. Zależy od tego, co chcesz zrobić. Myślę, że wszyscy zgodzilibyśmy się, że język jest znacznie lepszy, teraz pytanie brzmi, jak dobry ekosystem znajdziesz w swoim obszarze działalności.
W przypadku sieci Lift jest naprawdę solidną opcją. Nie wiem o komputerze ani telefonie komórkowym.

powiedzmy, że „nietrywialny” to wieloletni projekt, wydany przez 10-20 programistów.

To dużo ryzyka. Nagrody musiałyby być tego warte. W świecie korporacyjnych aplikacji biznesowych i średnich i dużych projektów podejmowanie ryzyka jest zwykle ograniczone. A raczej jest już wystarczająco dużo ryzyka, aby sobie poradzić ... Przewidywalność jest ważniejsza.

Wątpię, aby adopcja działała w ten sposób.

Bardziej prawdopodobne jest, że zacznie się jako garstka ludzi pracujących nad częścią, w której ryzyko jest ograniczone, taką jak POC, komponenty niekrytyczne, testy lub części, w których problem wydaje się być lepiej rozwiązany przez Scalę niż alternatywy (może jeśli coś wymaga aktor na przykład) ... W miarę jak narzędzia dojrzewają, społeczność rośnie, know-how rośnie w firmie, a następnie może się rozwijać.

Wykorzystując środowisko wykonawcze Java, Scala z pewnością jest gotowa na najwyższy czas. Jeśli możesz wdrożyć aplikację Scala, po wygenerowaniu kodu bajtowego zawsze powinna ona działać z tą konkretną wersją środowiska wykonawczego Java. Biblioteka oparta na Scali będzie działać jak każda inna biblioteka Java innej firmy, którą znasz.

Pod względem IDE, narzędzi do budowania i wszystkiego innego Scala nie ma tego samego poziomu proliferacji, co Java. Nie masz więc wielu frameworków opartych na Scali ani narzędzi opartych na Scali. To ma więcej wspólnego z popularnością Javy niż z rosnącą popularnością Scali. Scala ma funkcjonalne narzędzia, takie jak Scala IDE i sbt, narzędzie do budowania. Ale nie są one tak wyrafinowane, jak niektóre inne narzędzia pomocnicze w Javie.

Wybierające punkty z @huynhjl i @FarmBoy:

• Znalezienie wystarczająco dużej liczby doświadczonych programistów Scala może być trudne.

• Dogmat „najlepszych praktyk” dla Scali wciąż ewoluuje (*).

• Przewodniki stylu, konwencje itp. Wciąż ewoluują (*).

• Obsługa narzędzi wciąż się rozwija (*).

Łącząc je razem, być może lepszym pytaniem dla ciebie (siebie / samej) jest to, czy Twoja organizacja jest gotowa do użycia Scali w „nietrywialnym” projekcie? Czy masz ludzi, którzy mogą poradzić sobie z realizacją dużego projektu przy tak wielu rzeczach „wciąż ewoluujących”? Z drugiej strony, czy lepiej byłoby najpierw wykonać mniejszy projekt?

(* W rzeczywistości większość języków wciąż ewoluuje pod jednym lub więcej z tych aspektów. Problemem jest szybkość zmian / flux ... i to, czy Twój zespół sobie z tym poradzi.)

David Pollak z Good Stuff ma świetny post na blogu zatytułowany „ Funkcjonalne języki będą rządzić” (ale nie w tym roku), który trafia do drobiazgów języków funkcjonalnych w ogóle, a Scala szczegółowo, które bardzo polecam przeczytać, aby lepiej zrozumieć, czy Scala jest gotowa po raz pierwszy.

Nigdy nie rozumiał różnicy między enterprisei non enterpriseprogramy.

Używam tych samych programów w pracy, co w domu. W wolnym czasie nie używałbym miernego programu - dlaczego miałbym to robić?

Co to jest program nieprofesjonalny? Widziałem używane słabe aplikacje, ponieważ użytkownik nie wiedział lepiej, z powodu problemów ze zgodnością lub użytkownik odmówił wypróbowania czegoś nowego.

Jest to jednak problem przestarzałego oprogramowania i celów, które deweloper miał na myśli - nie języka, w którym program został napisany. Jeśli zaczniesz myśleć, w jakim języku jest napisany program, to już koniec: błąd.

Enterprise-aplikacja jest terminem marektingowym, który nie jest przydatny w poważnych dyskusjach.

A który klient wie, w jakim języku wykonałeś swoją pracę? Czasem im zależy, a czasem nie.

Możesz mieć pytania związane z dojrzałością języka - ale nie możesz odpowiedzieć na to pytanie dla wszystkich rodzajów przedsiębiorstw i wszystkich aplikacji.