Java, Java i co dalej?

piotrpo napisał(a):

@userek_jakis: Anegdoytczne, czyli wybrane 3 przykłady powiązałeś z językiem programowania i wydaje ci się, że to musi być właśnie ta przyczyna. W dodatku uparłeś się na aplikacje desktopowe z GUI, czyli obszar w którym Java ma bardzo mało do zaoferowania. Chcesz pisać aplikacje desktopowe, to użyj właściwego narzędzia. Chociaż nadal, wysoki czas reakcji na akcje użytkownika (czyli to słynne "lagowanie"), to w większosci przypadków błąd programisty, który nie potrafi / nie chce wykorzystać tych 32 rdzeni w moim komputerze i uparł się zrobić wszystko na jednym.

No nie, nie uparłem się na aplikacje desktopowe z GUI bo podałem też przecież przykład z testowaniem wykorzystującym javę.

? Przekonywać ludzi do tego, że aplikacja do obsługi eventów powinna używać więcej niż jednego procka kilku GHz-owego...

Android nie ma i nigdy nie miał "Javy" w sobie. Java to nie tylko język programowania, ale narzędzia do kompilowania plików java i uruchamiania wyników tej komplikacji. Czyli język ze swoją składnią, biblioteką standardową, kompilator i środowisko uruchomieniowe.

Nie pisałem nigdzie, że java jest dla mnie tylko językiem i zdaję sobie sprawę z tego co tutaj powyżej napisałeś. Zresztą o tym już była mowa:
Java, Java i co dalej?
i nie oponowałem przecież z tym co napisał user "bustard2".

Aplikacje na androida wykorzystywały (bo już tego nie robią w większości) język podobny do Java (ale nie identyczny), kompletnie inny kompilator, produkujący kompletnie inny bytecode uruchamiane są na czymś, co kompletnie nie ma nic wspólnego z JVM, czyli Dalvik VM i ART.
Obecnie większość aplikacji nawet nie używa Java jako wejścia. Większość developmentu przeszła na Kotlin, część aplikacji (gry) jest kompilowana natywnie z jakiegoś C++, do tego wynalazki jeszcze bardziej abstrakcyjne jak React Native, Flutter itd.

Jeśli piszesz prawdę to zastanawia mnie to co tutaj napisali:
https://www.geeksforgeeks.org/top-programming-languages-for-android-app-development/
https://www.netsolutions.com/insights/best-programming-languages-to-write-develop-android-apps/#:~:text=Frequently%20Asked%20Questions-,1.,and%20Basic%20are%20also%20used

Jak to się ma do twojej wypowiedzi.

Jeżeli chodzi o kawałek "kiedyś to były czasy, a teraz nie ma czasów", to przypomnij sobie jak wyglądały te aplikacje kiedyś i popatrz jak wyglądają dzisiaj. 20 lat temu, jak programista wstawił guzik do aplikacji, to odpowiedzialna za renderowanie tego guzika metoda rysowała 4 kreski na canvas robota skończona. Dzisiaj ta metoda dodatkowo wczytuje kilka fragmentów obrazka, dekoduje je do postaci bitmap, skaluje każdą z części, jak użytkownik najedzie myszką, to odpala się animacja. Równie dobrze możesz narzekać, że "kiedyś" takie allegro działało płynnie, a teraz bywa, że gdzieś coś się przytnie. Tylko kiedyś ładowała się statyczna stronka o rozmiarze liczonym w kilobajtach, teraz ładuje się cała aplikacja o rozmiarze liczonym w megabajtach. U mnie poszło coś koło 1.6 MB, czyli w praktyce coś koło 2 godzin pobierania danych na modemie.

Kiedyś kompy były dużo uboższe i to nie tylko pod względem ilości MHz-ów czy ilości pamięci...

Czyli co? Podsumowując:

• nie tylko java laguje
• jeśli coś laguje to winny jest tylko i wyłącznie programista

Podsumowując, winny jest ktoś, kto użył złego narzędzia do rozwiazania problemu. Ewentualnie nie potrafił prawidłowo użyć tego narzędzia.
Do tego w warstwie ui masa energii idzie w komin, bo ma być ładniej, responsywniej itd.

piotrpo napisał(a):

Podsumowując, winny jest ktoś, kto użył złego narzędzia do rozwiazania problemu. Ewentualnie nie potrafił prawidłowo użyć tego narzędzia.
Do tego w warstwie ui masa energii idzie w komin, bo ma być ładniej, responsywniej itd.

Ok, tutaj się odniosłeś do podsumowania. Ale co z pozostałymi kwestiami o których pisałem? A konkretniej:

1. Tutaj zaskoczyło mnie zestawienie tych dwu zdań (...)
2. ? Przekonywać ludzi do tego(...)
3. Jeśli piszesz prawdę to zastanawia mnie(...)
4. Kiedyś kompy były dużo uboższe(...)

I co to za język "podobny" do javy, o którym pisałeś? Chciałbym się tego dowiedzieć po prostu.

A co do DVM, ART i AOT to nie powiem starają się ludzie i dobrze jest o tym wiedzieć.

1. Pomijam w ty momencie projekty hobbystyczne. Jeżeli ktoś tworzy jakieś oprogramowanie, to chce, żeby mu za to zapłacono. W tej układance nie ma nikogo poza użytkownikiem, kto dostarczałby pieniędzy. Więc to użytkownik (tu możesz podstawić nazwę klient) za to płaci.
2. Nikt nie przekonuje ludzi do tego, że proste zadania wymagają jakiejś wielkiej mocy obliczeniowej. Jednak jeżeli napiszesz sobie procedurę obsługi jakiegoś kliknięcia, która synchronicznie wykona zapytanie do zewnętrznego serwera, zrobi parsowanie odpowiedzi i jej wyświetlenie na ekranie, to interface użytkownika będzie w tym czasie zamrożony. Tak będzie się działo niezależnie od użytego języka, więc nie jest to kwestia użytej technologii, tylko niekompetencji programisty. Ponieważ ś.p. prawo ś.p. Moora już nie obowiązuje, w każdym razie w kontekście pojedynczego wątku, to zrównoleglanie procesów stało się jednym z głównych problemów, jakie w tej chwili próbuje się rozwiązać w informatyce. Trochę pobocznie - apache kafka też jest napisane w Java, a potrafi działać wydajnie.
3. Twierdzenie, że aplikacje mobile pisze się w Java jest bardzo dużym skrótem myślowym. Wszystko zależy od tego jak dokładnie zdefiniujesz "Java". Jeżeli pytanie brzmi, czy znając Java będziesz musiał uczyć się innego języka, żeby napisać aplikację na Androida, to odpowiedź brzmi nie, bo faktycznie składnia, spora część biblioteki standardowej pozostaje bez zmian, z punktu widzenia klepacza kodu. Jeżeli patrzysz na to szerzej i definiujesz jako zestaw narzędzi dostarczonych przez Sun/Oracle to okaże się, że Android ma z nim bardzo mało wspólnego. Tego co było używane jako Java w Android, nie da się nawet na poziomie języka określić żadną konkretną wersją Java ze strony Oracle. Jeżeli chcesz głębszą historię z wątkiem "dej mmom chorom curke" to przeczytaj to https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.
4. Kiedyś komputery były dużo uboższe, ale stawiano dużo mniejsze wymagania funkcjonalne w odniesieniu do oprogramowania. To, że na win 3.11 był kalkulator, obecnie też jest, ale działa dużo wolniej robiąc to samo jest prawdą jedynie w odniesieniu do faktu, że wciąż oferuje te same działania matematyczne. Obecna wersja daje użytkownikowi zupełnie inne UI/UX, które pochłania pewnie więcej zasobów niż podstawowa funkcjonalność.

I już poza głównym wątkiem, piszesz wyłącznie o wydajności, a to jest jedynie jeden z aspektów decyzji o wyborze jakiejś technologii. Np. całe data science siedzi na Pythonie, chociaż wydajność tego języka jest mizerna, ale oferuje biblioteki typu scipy, matpy. Każdy wybór technologii, to nie tylko zalety, ale również koszty poniesione w jakichś obszarach. Gdyby istniała najlepsza technologia "ogólnie", to wszyscy byśmy używali jakiegoś X++. Np. na serwerze dużą zaletą Java było bezpieczeństwo i brak działania bezpośrednio na warstwie sprzętowej. Jest też czas developmentu, dostępność specjalistów, koszty utrzymania, łatwość rozwoju, dostępność bibliotek, łatwość integracji z innymi technologiami itd.

bustard2 napisał(a):

Bo bez Javy koszt powstania tych aplikacji mógłby być zbyt wysoki. Oczywiście są alternatywy, ale pytanie czy są one znacząco lepsze niż Java? Nie sądzę.

Jakbyśmy pisali w roku 2000, kiedy alternatywą był stary C++ i ewentualnie powolne języki skryptowe, to miałbyś rację. Jednak w tej chwili Java nie ma raczej przewagi nad konkurencją jeśli chodzi o szybkość tworzenia kodu. Wybór języków jest bardzo duży, istnieją języki w których pisze się szybciej, bezpieczniej i zarazem kod wynikowy jest porównywalny lub nawet bardziej wydajny. To Java musi gonić peleton jeśli chodzi o udogodnienia w samym języku. Dlatego argument że "może działa powolnie i zżera cały RAM, ale powstało szybciej" jest inwalidą.

Ja osobiście jestem bardziej produktywny w Rust niż w Java. Ilość czasu który oszczędzam na braku konieczności poprawiania błędów czy braku konieczności optymalizacji jest bardzo duża.

@Krolik:
Ja też wolę np. Kotlina, w którym pisze się kod dużo szybciej, ale mówimy o stosunkowo nowych językach. Java przez długi czas zbudowała dobrą pozycję na rynku m. in. przez sprawność, z jaką tworzy się w niej serwisy webowe. A z tym 2000 zdecydowanie przesadziłeś.

@Krolik: Tylko obecnie "działa wolno i zżera cały RAM" jest również nieprawdą. Z drugiej strony mamy też zupełnie inaczej wyglądający rynek aplikacji, na którym:

• Aplikacje desktopowe są niszą.

• Aplikacje mobilne stają się niszą

• Zwiększeniu uległa liczba platform sprzętowych i koniecznych do wspierania systemów operacyjnych.

• Moc obliczeniowa i RAM są tanie.

  Oczywiście wszystko zależy (a przynajmniej powinno) od tego co konkretnie chcemy wyprodukować, ale:

  1. Aplikacje desktopowe - Java się do nich nie nadaje. W szczególności nie nadaje się do nich JavaFX. Może w tej rodzinie języków używalny będzie Kotlin multiplatform, nie wiem. Raczej stawiam na rozwój wynalazków jak Flutter, React Native itp. Jeżeli ktoś się ogranicza do Windows, to pewnie .NET będzie dobrą opcją.
  2. Aplikacje mobilne - tutaj brak dobrych uniwersalnych alternatyw. Problemem jest iOS/iPad OS z całym swoim rezerwatem Swift i względnie prostą integracją z C++. Z drugiej strony mamy Androida, gdzie to C++ jest do bani, paradoksalnie ze względu na wydajność integracji pomiędzy kodem natywnym, a ART'owym
  3. Backend, oczywiście są języki skryptowe (NodeJS, PHP, Python), ale moim skromnym zdaniem, wprowadzają one więcej problemów niż rozwiązują. Rozwiązania natywne (kompilowane) mają swoje problemy i do backendów nadają się średnio. Pozostają 2 grupy technologii: te oparte na JVM i te z grupy .NET. Nie widzę dużych różnic pomiędzy obiema grupami, ale ze wzglądu na to, że MS dopiero niedawno zdecydował się zauważyć, że nawet korpo nie chcą stawiać serwerów na Windows, Java ma tu dużo większą popularność. Co za tym idzie więcej bibliotek, więcej ludzi do pracy, więcej ogłoszeń - efekt kuli śnieżnej, ale to nie przyczyny mają znaczenie, tylko skutki - jeżeli nie ma argumentów czysto technicznych, to do głosu dochodzą argumenty organizacyjne - łatwiej znaleźć programistę Java ze znajomością Springa, niż programistę C# ze znajomością Core.

To wszystko wyżej, oznacza, że jeżeli przychodzi biznes i mówi "chcę system do obsługi parkingu", to wyjściowym stosem technologii jest Java / wariacje tego języka. Mam jakiś tam zestaw narzędzi opanowany i rozpoznany, wiem, ze zadanie da się zrealizować przy użyciu tych narzędzi, to nie będę na siłę wymieniał całego stosu na inny, którego nie mam rozpoznanego. Moge się zgodzić na użycie innej bazy danych, innej usługi kolejek/tematów, czy nawet innego języka z danej rodziny (Kotlin, Scala itp.), bo wiem, że co by się nie stało, będę w stanie poprowadzić projekt do jakiegoś przyzwoitego poziomu. Natomiast, pomimo, że jestem raczej "postępowym architektem", nie zgodzę się np. na trzepnięcie całości z defaultu w NodeJS, którego nie znam ani ja, ani 80% zespołu projektowego. Mogę się ewentualnie zgodzić na zrobienie w tej technologii jakiejś drobnej usługi, o której wiem, ze jak coś, to ją w 2 tygodnie jesteśmy w stanie przepisać na inny język.

Rozwiązania natywne (kompilowane) mają swoje problemy i do backendów nadają się średnio.

Właśnie do backendów nadają się lepiej, a szczególnie do mikroserwisów, choćby ze względu na znacznie mniejsze zużycie zasobów (a w przypadku np Rust również wyższą stabilność i bezpieczeństwo). Tam gdzie płaci się za użyte zasoby, np. w chmurze i gdzie te koszty zarząd widzi czarno na białym, coraz więcej widzę Rust i Go, a coraz mniej Javy. Jak pokazesz biznesowi że jeden VPS ogarnia to co kiedyś ogarniał klaster, to nagle okazuje się że jednak "wincyj serwerów" nie jest akceptowalnym rozwiązaniem ;)

Sztandarowa zaleta Javy, czyli przenośność binarek na różne platformy nie ma kompletnie żadnego znaczenia na backendzie, bo tam masz pełną kontrolę nad architekturą sprzetową i systemem, więc konieczność kompilacji na dany target nie jest wadą. Kompilacja natywna jest (drobnym) problemem przy dystrybucji oprogramowania działającego u wielu klientów, bo musisz wtedy skompilować pod różne architektury. Dlatego właśnie Java zdobyła popularność najpierw w web jako aplety, bo tam jej przenośność binarna była dużą zaletą. Potem na mobilkach i desktopie (mobilne też głównie ze względu na WORA - mnogość telefonów i ich systemów była w tamtych dawnych czasach w okolicach 2005 koszmarna).

Oczywiście jest efekt kuli śnieżnej i dlatego po pewnym czasie Java dotarła i na serwery, podobnie zresztą jak Node.JS.

To już oczywiście jest opinia, ale wg mnie Java na backendzie, poza systemami legacy, nie ma za bardzo sensu, za wyjątkiem sytuacji kiedy musimy skorzystać z jakiejś biblioteki dostępnej tylko w ekosystemie Javy lub po prostu mamy zespół który tylko umie w Jave, czyli przyczyny pozatechniczne.

@Krolik: Trochę się zgadzam, trochę się nie zgadzam z tym co piszesz. Oczywiście na backendzie wydajność ma (miewa) znaczenie, bo potrafi się bezpośrednio przełożyć na koszty utrzymania systemu. Natomiast w najbliższym czasie wygląda na to, że czeka nas kolejny raz mnogość architektur sprzętowych, bo coraz głośniej słychać o ARM'ach na serwerach. Natomiast nie zgadzam się, że ta przenośność artefaktów to główna cecha Java, która spowodowała odwrót z CGI. Moim zdaniem głównymi przyczynami (oprócz dyskusyjnego przyśpieszenia deploymentu), były pułapki zastawiane na programistę przez C(++), krzywa nauki i bezpieczeństwo rozwiązania. Możliwe, że GO rozwiązało ten problem, ale uruchamianie programu mającego dostęp bezpośrednio do sprzętu, w środowisku dostęnym z zewnątrz, to proszenie się o całą kolekcję problemów związanych właśnie z bezpieczeństwem. Błędy w oprogramowaniu to w przypadku serwerowego C++ właściwie z automatu błędy bezpieczeństwa. W dodatku o ile w przypadku maszyny wirtualnej problem kończy się na ogół na wywaleniu jakiejś usługi, to w przypadku takiego C++ może dość łatwo podnieść zagrożenie do RPC.

Piszesz o problemach typowych dla C i C++ związanych z bezpieczeństwem pamięci. Ale to jest przeszłość. Te problemy nie występują we współczesnych językach natywnie kompilowanych takich jak Rust, Go, Swift - one wszystkie są językami o bezpiecznym zarządzaniu pamiecią.

BTW: Nie trzeba wcale uciekać poza sandbox JVM aby zrobić remote code execution w Javie. Użytkownicy log4j zapewne coś mogą o tym opowiedzieć ;). Jedna prosta libka do logowania i 3 różne RCE: https://logging.apache.org/log4j/2.x/security.html

No i jeszcze druga sprawa - teraz nie wdraża się aplikacji na gołym systemie operacyjnym tylko praktycznie wszystko odpala się w kontenerach, które stanowią dodatkową warstwę izolacji. W najgorszym przypadku też wywali się usługa.

Natomiast w najbliższym czasie wygląda na to, że czeka nas kolejny raz mnogość architektur sprzętowych, bo coraz głośniej słychać o ARM'ach na serwerach.

Nie ma znaczenia. Dany system budujesz na konkretną architekturę, która jest Ci z góry znana.
Przecież i tak kompilujesz aplikacje przy każdym kolejnym wydaniu. Przekompilowanie wszystkiego na inną architekturę to jest kwestia jednego parametru dla kompilatora.

Przenośność binarna jest potrzebna jeśli nie kontrolujesz docelowej architektury. Czyli dajesz program i nie wiesz na czym klient go uruchomi. Wtedy WORA jest zaletą bo nie musisz przygotowywać N paczek, a wystarcza jedna. To dotyczy jednak aplikacji klienckich a nie backendów. Niemniej mala to zaleta bo te N paczek robi obecnie CI/CD, więc czy jedna paczka czy więcej to z punktu widzenia programisty ilość pracy ta sama.

@Krolik ale nie ma nic za darmo :D Wchodząc w te języki o jakich piszesz już ze swojej definicji tracisz opcje na dopisywanie kodu i kompilację w czasie działania procesu.

Gdzie to może mieć sens, a no w:

1. w czasie developmentu, bo apka chodzi i dopisujesz kod obserwując na bieżąco aktualne skutki. Szybsza pętla sprzężenia zwrotnego to przewaga nad typowym: zbuduj, dojdź do oczekiwanego stanu i zobacz wynik.
2. w czasie produkcji :D Raczej to nie jest najlepszy sposób do rozwoju aplikacji, ale przydatne w trakcie diagnostyki, bądź gdy jeszcze nie ma interfejsu webowego dla admina.
3. funkcyjnych językach, bo przy persistent collections zoptymalizowany GC to istotna korzyść, a JVM w tym aspekcie daje szerszy wybór. Mniej przerw ma znaczenie w czasie zapytań
4. i idąc za ciosem, to w funkcyjnych bazach danych takich jak xtdb (dla niewtajemniczonych, funkcyjna baza to taka, która domyślnie nie zamazuje starych danych i która pozwala je odpytać dla dowolnego punktu w czasie).

Hot reload kodu natywnego jest możliwy: https://learn.microsoft.com/en-us/visualstudio/debugger/hot-reload?view=vs-2022

Co do użycia tego na produkcji to myślałem, że rozmawiamy poważnie.

funkcyjnych językach, bo przy persistent collections zoptymalizowany GC to zaleta

Użycie języka kompilowanego statycznie nie wyklucza GC. Ba, akurat tak się składa że pracuję teraz nad apką w Rust, która używa kolekcji lockless (flurry) z GC opartym na epokach. Różnica między tym GC a GC z JVM jest jednak taka, że tutaj nie trzeba skanować i defragmentować sterty, a GC dotyczy tylko jednej malutkiej struktury danych, więc nie ma pauz. Nawet na mikrosekundę.
Jakby ktoś chciał o tym więcej poczytać to tu jest artykuł opisujący jak to się robi i jakie są efekty:
https://aturon.github.io/blog/2015/08/27/epoch/

@Krolik: Ja nie przeczę, że uzycie rozwiązań bardziej wydajnych nie jest kuszące, ale spójrz na to z 2 strony. Jakiś tam niewielki projekt backendowy,, który ma coś robić to kilka milionów złotych, z których niewielka jedynie część to koszty chmury. Powiedzmy, że te płacę za VM'ki na których chodzi aplikacja około 10k USD rocznie. Powiedzmy też, że będę mógł zredukować ich koszt o 20%, co i tak jest dyskusyjne, bo muszę dbać o niezawodność systemu, więc poniżej pewnych wartości nie zejdę, jeżeli chcę mieć na tych klastrach jakąś tam nadmiarowość. Wprowadzisz do projektu dodatkowe ryzyko za pomijalne wartości oszczędności?
Do tego dochodzą problemy organizacyjne z którymi musiałbym się zmierzyć:

• Skrzyczy mnie uber architekt (no dobra, to przeżyję)
• Skrzyczy mnie security i będę musiał szukać sposobu na statyczną analizę kodu, bo poświęcony przez korpo tool nie działa z Rustem
• Muszę zaplanować jak te dodatkowe artefakty będą testowane (co pewnie coś tam będzie kosztować)
• Nie rozbuduję zespołu tak łatwo jak w językach głównego nurtu
• Ponoszę zwiększone ryzyko, że niszowa technologia spowoduje jakieś problemy
• Muszę sprawdzić przed uruchomieniem projektu, czy język oferuje wsparcie dla wszystkiego z czym potencjalnie będę musiał się zintegrować (bazy danych, kolejki, redisy i inne stwory).

Do tego wszystkiego, ja już parę lat w tej branży siedzę i czytając jak to golang jest szybszy od Java, ma lepszą krzywą nauki i resztę zalet, mam deje vu, bo ja to już czytałem ileś tam razy, na głównych stronach praktycznie każdego języka programowania jaki powstał, w tym Java, która tez obiecywała dorównanie wydajnością C++ :)

Ale to już teraz rozmawiamy o inercji przy zmianie technologii. I ja się z tym wszystkim zgadzam. Z tego powodu masz całkiem pokaźną liczbę systemów napisanych w COBOLU, działających do dzisiaj. Generalnie jeśli posiadasz zespół który umie X a nie umie Y, to wchodzenie w Y nie musi być dobrym pomysłem, niezależnie od tego czy Y jest lepsze samo w sobie.

Dlatego myślę, że Java będzie z nami jeszcze przez wiele dekad, bo napisano w niej tyle kodu, ze on tak sobie nie zniknie ani nie zostanie szybko przepisany.

Ale jednak ja widzę trend choćby u nas w firmie - do nowych rzeczy coraz rzadziej jest wybierana Java, a coraz więcej osób jest zatrudnianych ze znajomością Golang i Rust.

czytając jak to golang jest szybszy od Java, ma lepszą krzywą nauki i resztę zalet,

Golang jest wydajniejszy od Javy na JVM w kilku kwestiach (szybkość startu, szybkość budowania projektu, mniejsze zapotrzebowanie na pamięć, mniejsze obciążenie GC, mniejsze paczki wynikowe), a w wielu pozostałych jest dość zbliżony. Kompilator ma dość przeciętny jeśli chodzi o optymalizację kodu, korzysta też bardzo mocno z polimorfizmu czasu wykonania no i nadal ma pauzy GC, choć dość małe. IMHO wydajnościowo Golang i Java to nadal druga liga. Pierwsza to C, C++, Rust, D i Zig.

Java, która tez obiecywała dorównanie wydajnością C++

Nie zauważyłem aby twórcy Go twierdzili, że Go miał dorównywać C++ wydajnością. Raczej zawsze to był język pod zastosowania do których Google tradycyjnie używało Javy. Filozofia rozwoju Go jest taka, że bardziej liczy się szybkość kompilacji i łatwość nauki niż szybkość kodu wynikowego. Pod tym względem IMHO to najbliższy odpowiednik Javy, wśród nowych języków.

Wydajnością do C++ ma dorównywać Rust. I tak faktycznie jest w 99% przypadków (jest też 1% przypadków gdzie przewyższa).

Krolik napisał(a):

Właśnie do backendów nadają się lepiej, a szczególnie do mikroserwisów, choćby ze względu na znacznie mniejsze zużycie zasobów (a w przypadku np Rust również wyższą stabilność i bezpieczeństwo). Tam gdzie płaci się za użyte zasoby, np. w chmurze i gdzie te koszty zarząd widzi czarno na białym, coraz więcej widzę Rust i Go, a coraz mniej Javy. Jak pokazesz biznesowi że jeden VPS ogarnia to co kiedyś ogarniał klaster, to nagle okazuje się że jednak "wincyj serwerów" nie jest akceptowalnym rozwiązaniem ;)

Tylko, że napisanie czegoś w Rust czy C++ nie gwarantuje, że będzie szybciej, czasem nawet będzie wolniej (np. kod w C :-) ).
Zużycie CPU i IO przeważnie zależy od architektury (często świadomych decyzji) i błędów, które programiści popełniają.

Ja też widzę coraz mniej javy, za to coraz więcej Rusta, Go ale jeszcze więcej Haskella i Scali. Gdzie Scala, to nie jest demon szybkości (teoretycznie) w porównaniu z javą.

@jarekr000000: Ja mam wrażenie, że największa przewaga "nowych" jężyków, to ludzie, którzy chcieli się czegoś nauczyć, coś zrozumieć, poeksperymentować itd. Zanim odezwie się jakiś urażony, podkreślę jedynie, że mam na myśli statystykę. Z drugiej strony, im bardziej te technologie będą popularne, tym bardziej zbliżą się pod tym względem do Java. Zresztą było to widać w danych, które jakiś czas temu przytoczyłeś, wg. których programiści np. Scala zarabiają więcej niż programiści Java. Moja hipoteza jest taka, że ta statystyczna różnica bierze się ze statystycznej różnicy w poziomie umiejętności.
Co do wydajności samego języka, w sensie który język szybciej wykona quicksorta, czy innego dijkistrę - w większości realnych zastosowań backendowych nie ma to żadnego znaczenia, bo obliczenia mają śladowy wpływ na czas działania systemu w porównaniu do np. zapisu/odczytu z bazy danych, czy komunikacji po sieci. Wykorzystanie pamięci jakiś tam wpływ już ma, bo można upchnąć więcej kontenerów na tym samym node'ie, ale nadal nie jest to coś co mogłoby decydować.

Co do wydajności samego języka, w sensie który język szybciej wykona quicksorta, czy innego dijkistrę - w większości realnych zastosowań backendowych nie ma to żadnego znaczenia, bo obliczenia mają śladowy wpływ na czas działania systemu w porównaniu do np. zapisu/odczytu z bazy danych, czy komunikacji po sieci.

Pewien jesteś?

https://benhoyt.com/writings/io-is-no-longer-the-bottleneck/

Przy dyskach o przepustowości 2+ GB/s i 100k IOPS oraz sieciach 25 Gbps prawdę powiedziawszy trudno być I/O bound nawet pisząc turbo-zoptymalizowany kod w asemblerze. :P

Tak, zapewne nic tam nie liczy quicksorta, bo głównym spowalniaczem realnego softu obecnie są misie. Cache misie. ;) I to że przeciętnie strona www potrzebuje kilkuset ms na wyświetlenie to nie są opóźnienia sieci ani dysków, tylko jednak wszystkie CPU które masz po drodze, które muszą przewalić tony danych.

Krolik napisał(a):

Tak, zapewne nic tam nie liczy quicksorta, bo głównym spowalniaczem realnego softu obecnie są misie. Cache misie. ;) I to że przeciętnie strona www potrzebuje kilkuset ms na wyświetlenie to nie są opóźnienia sieci ani dysków, tylko jednak wszystkie CPU które masz po drodze, które muszą przewalić tony danych.

Z mojego doświadczenia to głównym spowalniaczem realnego softu są:
a) redundantne IO - czyli niepotrzebne wielokrotne odczyty tych samych, często nawet niepotrzebnych danych (nawet głupie select * tu wchodzi), aczkolwiek dotyczy to też zbędnych wołań http i czytania plików wielokrotnie (np. configi)
b) błędy - np. często wycieki pamięci skutkują spowolnieniem aplikacji, błędy na hashCode, pomyłki w algorytmach, błędy skutkujące wielokrotnym czytaniem danych (patrz punkt a).

Cache misie to wchodzą dopiero do gry jak powyższe przestają być problemem, co w typowej aplikacji się w zasadzie nie zdarza.

@Krolik: Jestem całkiem przekonany, że w typowym weź request z wejścia, zrób z nim coś, ale nie za wiele, wrzuć wynik do bazy danych, to "zrób z nim coś, ale nie za wiele" będzie pomijalne, chyba, że będzie wymagało dodatkowej komunikacji.

A jak tam wygląda sprawa z istniejącymi JVM i wsparciem optymalizacji pod konkretne rozszerzenia architektur CPU (SSE, Neon) czy wsparcie SIMD? Bo tak patrząc krzywym okiem to ze śmiercią prawa (i twórcy) Moore'a przyszłość CPU wygląda tak że coraz więcej rzeczy będzie pchane w customowe ASICi obudowujące rdzenie ogólnego użytku a których użycie będzie się wiązało prawdopodobnie właśnie poprzez rozszerzenia standardowego zestawu instrukcji.

Pytam z ciekawości bo kiedyś słyszałem że HotSpot w ogóle nie miał możliwości (albo chęci) korzystania z SSE co w niektórych benchmarkach dawało mu mocno w kość.

loza_prowizoryczna napisał(a):

A jak tam wygląda sprawa z istniejącymi JVM i wsparciem optymalizacji pod konkretne rozszerzenia architektur CPU (SSE, Neon) czy wsparcie SIMD? Bo tak patrząc krzywym okiem to ze śmiercią

Konkretnie to od co najmniej wersji hotspot 1.5 (już pełnoletnia) jvm korzysta z SSE - rozkazów i rejestrów. (generalnie nie wiem od kiedy korzysta, ale w czasach późnego 1.5 sprawdzałem).
Ale rozkazy i rejestry to nie jest faktycznie sensowne wektoryzcja - bo tej z tego co wiem to nadal JIT hotspota nie robi.

To jest podobnie istotnie zmienione/poprawiane dopiero w graalvm, a szczególnie w wersji enterprise. Ale tu bazuje na opowieściach developerów tego graala - nie sprawdzałem jak działa, a akurat nie miałem kodu, gdzie to by coś dało.

loza_prowizoryczna napisał(a):

Pytam z ciekawości bo kiedyś słyszałem że HotSpot w ogóle nie miał możliwości (albo chęci) korzystania z SSE co w niektórych benchmarkach dawało mu mocno w kość.

To bardziej problem Javy niż HotSpota. Wymuszony alligment obiektów, boxing czy type-erasure generyki sprawiają, że ciężko zaaplikować SSE, bo layout obiektów w pamięci się nie zgadza

slsy napisał(a):

To bardziej problem Javy niż HotSpota. Wymuszony alligment obiektów, boxing czy type-erasure generyki sprawiają, że ciężko zaaplikować SSE, bo layout obiektów w pamięci się nie zgadza

Ale to akurat java/ jvm nie ma żadnego wymuszonego alignmentu w pamięci - to nie C. Zresztą graal z tego mocno korzysta.

jarekr000000 napisał(a):

Ale to akurat java/ jvm nie ma żadnego wymuszonego alignmentu w pamięci - to nie C. Zresztą graal z tego mocno korzysta.

To prawda, co nie zmienia tego, że liczy się całość. Przeciętny programista będzie tworzył obiekty, których minimalny rozmiar to 16 bajtów zawierające dużo niepotrzebnych danych utrudniających SSE jak object header. Póżniej te obiekty będą wrzucane do kolekcji, która musi trzymać referencje, bo Java jeszcze nie umie into inlinowanie obiektów w miejscu alokacji.

IMO ważniejsze jest mówienie o tym jak będzie wyglądał przeciętny program vs mocno zoptymalizowany program, ale do utrzymania aż do kod, żeby benchmark wyszedł dobrze niż to na co dana platforma zezwala

Nie jestem pewien czy w tym wątku wszystko co zostało napisane jest na poważnie - więc może podsumujmy:

#if trolling_enabled
  java jest najlepsza, java jest szybsza od rust, c++ i c i wykonuje pętlę nieskończoną w czasie dużo krótszym (a co najważniejsze w czasie mierzalnym) od każdego z tych języków
#else
  java może i laguje, ale za to zżera całą pamięć
#endif

I która z tych kwestii jest prawdziwsza? ;)

Co taki biedny junior (jeśli przypadkiem czyta ten wątek) ma wybrać jako wiodący język po lekturze tego wątku?

userek_jakis napisał(a):

I która z tych kwestii jest prawdziwsza? ;)

Ani jedna, ani druga nie jest prawdziwa - więc tak naprawdę są sobie równe.

Co taki biedny junior (jeśli przypadkiem czyta ten wątek) ma wybrać jako wiodący język po lekturze tego wątku?

Akurat jeśli junior ma choć trochę w głowie to przeczyta wątek i zrozumie, że za większość problemów wydajnościowych aplikacji w Javie nie odpowiada sama Java, tylko zły design i/lub implementacja.

wartek01 napisał(a):

userek_jakis napisał(a):

I która z tych kwestii jest prawdziwsza? ;)

Ani jedna, ani druga nie jest prawdziwa - więc tak naprawdę są sobie równe.

Co taki biedny junior (jeśli przypadkiem czyta ten wątek) ma wybrać jako wiodący język po lekturze tego wątku?

Akurat jeśli junior ma choć trochę w głowie to przeczyta wątek i zrozumie, że za większość problemów wydajnościowych aplikacji w Javie nie odpowiada sama Java, tylko zły design i/lub implementacja.

Dobrze, przekonałeś mnie swoją argumentacją więc zmieniam zdanie. Zmodyfikujmy if-a:

#if trolling_enabled
  java jest nienajlepsza, nawet nie potrafi wykonać pętli nieskończonej w mierzalnym czasie, ale od dłuższego czasu pracują nad tym
#else
  java wcale nie laguje i to user jest zbyt niecierpliwy i chciałby mieć wszystko od razu, ale pamięci to mógłby se dokupić skąpiec jeden
#endif

userek_jakis napisał(a):

#if trolling_enabled
  java jest nienajlepsza, nawet nie potrafi wykonać pętli nieskończonej w mierzalnym czasie, ale od dłuższego czasu pracują nad tym
#else
  java wcale nie laguje i to user jest zbyt niecierpliwy i chciałby mieć wszystko od razu, ale pamięci to mógłby se dokupić skąpiec jeden
#endif

niektóre kompilatory c++ (np. clang) wycinają pętle nieskończone bez efektów ubocznych, bo według specyfikacji jest to undefined behavior

userek_jakis napisał(a):

Dobrze, przekonałeś mnie swoją argumentacją więc zmieniam zdanie.

No i dalej się nic nie zmienia bo po prostu twoje wnioski sprowadzają się do przedstawienia dwóch pokracznych tez.

userek_jakis napisał(a):

Co taki biedny junior (jeśli przypadkiem czyta ten wątek) ma wybrać jako wiodący język po lekturze tego wątku?

Stack Overflow.