Java, Java i co dalej?

wartek01 napisał(a):

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.

Ok, to może teraz bez wygłupów:
Tego co pisałem wcześniej nie bierz osobiście. To trollowanie nie było wymierzone w ciebie tylko w pewne podejście.

Jak myślisz po co założyłem ten wątek? Tylko po to, żeby pohejtować sobie javę albo javopodobne rozwiązania?
Nie. Próbuję się po prostu przebić do świadomości niektórych osób.
Osób, które żyją sobie w pewnej bańce nieświadomości i nic poza nią ich nie interesuje...

A przy okazji ja też dowiedziałem się kilku rzeczy.

userek_jakis napisał(a):

Nie. Próbuję się po prostu przebić do świadomości niektórych osób.
Osób, które żyją sobie w pewnej bańce nieświadomości i nic poza nią ich nie interesuje...

i przebiłeś się?

ktoś zrobił do d**y rozwiązanie, bo odpala całego jvma w pętli, a ty zaczynasz filozofować i przebijać się do świadomości. niech gostek wywali skrypt z tą pętlą i całość logiki wrzuci do kodu javowego, a potem odpali jvma raz i niech chodzi, aż wszystko przemieli. proste :)

ewentualnie możecie zrobić ultra prosty serwer restowy (do takich jest pewnie mnóstwo gotowców w javie), który będzie pobierał dokładnie te same argumenty co jvmka teraz i to samo wypluwał. w takim przypadku też unikamy odpalania jvmki w pętli. rozwiązań jest wiele.

Wibowit napisał(a):

ktoś zrobił do d**y rozwiązanie, bo odpala całego jvma w pętli,

Piękno IT. Języki migrują w stronę bardziej deklaratywnych udając że są imperatywne (co by się starzy nie zorientowali), starzy odpalają benchmarki i widzą że wszystko działa wolniej (milisekundy, no ale kwestia skali) więc wracają do starych sztuczek, stare sztuczki wymagają zrozumienia jak działają trzewia kompilatorów/JIT i sztuczek optymalizacyjnych które stosują ich autorzy.

Wchodzi nowy hardware, autorzy kompilatorów dostają możliwość implementacji nowych strategii optymalizacji pod dane arch, dodają to i przy okazji okazuje że stare sztuczki które wcześniej działały nagle działają 10x wolniej albo w ogóle wywalają programy w losowych miejscach więc trzeba rezygnować i iść konserwatywnie (wolno).

Młode wyposzczone studenty inżyniery z uniwerków słysząc narzekania swoich psorków dochodzą do wniosku że jedynym rozwiązaniem jest pozbycie się balastu przeszłości więc następuje nowy wysyp języków - części z nich udaje się przetrwać, nawet przebijają się do mainstreamu + dostają wsparcie od dużych graczy. I tak się powoli żyje na tej wsi.

Parafrazując jednego moderatora - trzeba (sobie) robić dobrze.

Wibowit napisał(a):

ktoś zrobił do d**y rozwiązanie, bo odpala całego jvma w pętli, a ty zaczynasz filozofować i przebijać się do świadomości. niech gostek wywali skrypt z tą pętlą i całość logiki wrzuci do kodu javowego, a potem odpali jvma raz i niech chodzi, aż wszystko przemieli. proste :)

ewentualnie możecie zrobić ultra prosty serwer restowy (do takich jest pewnie mnóstwo gotowców w javie), który będzie pobierał dokładnie te same argumenty co jvmka teraz i to samo wypluwał. w takim przypadku też unikamy odpalania jvmki w pętli. rozwiązań jest wiele.

Wszystko sprowadza się do tego co i po co mierzysz. Benchmark z odpalaniem jvma w pętli jest jak najbardziej ok, jeśli potrzebujesz ewaluacji jvma w kontekście odpalania na nim małych tooli z linii poleceń. Benchmark w sumie potwierdza to co wszyscy wiedzą od dawna: że Java+JVM nie nadaje się do narzędzi, które mają mieć niski czas startu. Python zresztą też nie.

Ale oczywiście wyniki nie ekstrapoluja się na backendy serwerów.

Wibowit napisał(a):

userek_jakis napisał(a):

Nie. Próbuję się po prostu przebić do świadomości niektórych osób.
Osób, które żyją sobie w pewnej bańce nieświadomości i nic poza nią ich nie interesuje...

i przebiłeś się?

No tak jak pisałem: dopiero próbuję i nadal będę. Efekty może będą. Tylko jakie? Zastanawiam się też czy ewentualna moja sugestia nie zostanie zakwalifikowana jako "minor" - czyli do wykonania w terminie "nigdy".

ktoś zrobił do d**y rozwiązanie, bo odpala całego jvma w pętli, a ty zaczynasz filozofować i przebijać się do świadomości. niech gostek wywali skrypt z tą pętlą i całość logiki wrzuci do kodu javowego, a potem odpali jvma raz i niech chodzi, aż wszystko przemieli. proste :)

? Nie pisałem nigdzie, że te testy są odpalane w pętli... Ale teraz tak się zastanawiam... tych testów tam jest uruchamianych trochę, może faktycznie one sobie lecą w pętli obsługiwanej przez skrypt? Ale odpalanie jvm-a w każdej iteracji osobno to byłoby barbarzyństwo.

ewentualnie możecie zrobić ultra prosty serwer restowy (do takich jest pewnie mnóstwo gotowców w javie), który będzie pobierał dokładnie te same argumenty co jvmka teraz i to samo wypluwał. w takim przypadku też unikamy odpalania jvmki w pętli. rozwiązań jest wiele.

Tak czy siak niestety teraz mam inne zadanko i nie mogę sprawdzić więcej szczegółów.

Krolik napisał(a):

Wszystko sprowadza się do tego co i po co mierzysz. Benchmark z odpalaniem jvma w pętli jest jak najbardziej ok, jeśli potrzebujesz ewaluacji jvma w kontekście odpalania na nim małych tooli z linii poleceń. Benchmark w sumie potwierdza to co wszyscy wiedzą od dawna: że Java+JVM nie nadaje się do narzędzi, które mają mieć niski czas startu. Python zresztą też nie.

jarekr000000 napisał:

Dokładnie, aczkolwiek tu chyba jest inny kanał (ale tylko zgaduje!!!) - bo to wcale nie miał być tool do odpalania z linii poleceń, tylko OP tak to odpala, z sobie znanych powodów. Btw. sam swego czasu odpalałem javę jako CGI w apachu :-) (też było źle).

Odpowiem na obie wiadomości tutaj.

Tutaj nie chodzi o benchmark javy - bo nie mierzę czasu wydajności javy tylko to jest tak:
Jest sobie stronka www, która wywołuje cały proces testowania wielu różnych aspektów działania pewnego programu. Czyli testuje ten program na różne scenariusze testowe. Takie testy w ten sposób uruchomione lecą sobie godzinami i żebym nie musiał tracić czasu na czekanie aż wszystkie testy przelecą to dostałem opis jak jeden z tych testów wywołać z cmdline. W czasie próby uruchamiania tego jednego testu z cmdline uruchamiana jest java po to, żeby przeparsować ileśtam plików tekstowych i na wyjściu wygenerować jedną linijkę z konkretnymi parametrami. Ta jedna linijka z parametrami jest potem przekazywana do właściwego programu testującego ten mój program. Czyli w skrócie używany jest jakiś programik w javie jako parser i generator jednego stringa po to żeby wyrzucić go potem na stdout.

Żeby już nie męczyć się z tą javą po prostu spisałem sobie to co ona generuje na wyjściu dla iluśtam kombinacji i wywołuję ręcznie program testujący z tymi spisanymi parametrami.

Zakładam, że teraz już ten opis jest bardziej zrozumiały.

Ale w tej chwili mam inne zadanko i nie za bardzo możliwości sprawdzić co i jak się tam dzieje w skryptach używających tej javy jako parsera/generatora.

Ja mogę pisać z własnego doświadczenia - pisałem / pisze oprogramowanie działające zwykle głęboko na backendzie, czyli system baz danych Cassandra/Dse/Astra. I tak się składa że z historycznych powodów akurat w Javie i prędko to się nie zmieni.

Ale ostatnio też miałem do czynienia z nowszymi językami - Golang i Rust, gdzie akurat w przypadku Rust osobiście użyłem tego do pewnego produkcyjnego kawałka kodu (Golanga za to używa dużo innych ludków u nas).

I generalnie konkluzja jest taka:
W Javie jest multum rzeczy na które musimy uważać aby nie spowodować katastrofy wydajnościowej. Ilość czasu spedzonego na optymalizację jest znaczna. Liczba udogodnień Javy, których nie wolno używać na wydajnościowej ścieżce krytycznej również jest znaczna, przez co kod przypomina często C. Również znacznie jest ilość czasu na poprawianie błędów związanych z zarządzaniem zasobami (wycieki) oraz ze współbieżnością. Jako ciekawostkę mogę podać że kod do liczenia referencji do plików w Cassandra ma niemal tysiąc linii i nadal używanie go jest o wiele trudniejsze i bardziej bledogenne niż smart pointery z C++. Coś co w innych językach jest wbudowane tutaj musiał ktoś napisać i nie był to wcale trywialny kod (co więcej, znajdowaliśmy w nim błędy wiele lat później).

Po przesiadce na Rust ilość czasu poświęcanego na optymalizację oraz na poprawianie ww błędów spadła niemal do zera. Do tego pierwsze wersje czegokolwiek są zwykle 3-10x wydajniejsze niż zoptymalizowana Java, bez robienia czegokolwiek szczególnego i mimo używania bardzo wysokopoziomowych konstrukcji języka. Wreszcie mogę pisać kod skupiając się głównie na czytelności, prostocie, łatwości utrzymania, a nie na tym aby niechcący nie zdenerwować GC.

Dla mnie to jest game changer i nie mogę na jave więcej patrzeć.Ostatecznie liczy się szybkość wytwarzania oprogramowania spełniającego wymagania i Java mnie mocno pod tym względem hamuje.

A, no na koniec, są jeszcze takie przyziemne rzeczy jak tooling, np systemy budowania projektu. Gradle vs cargo to po prostu przepaść jeśli chodzi o ergonomię.

Tak jak wspominałem już wcześniej, że planuję opisać w osobnym wątku całą sprawę i że "sprawa jest grubsza" - utworzyłem nowy wątek. O tutaj:
Kto zyskuje a kto traci?

A tutaj celem uzupełnienia jeszcze tego wątku w kontekście tego co opisałem w tym nowym to:

• a propos "przebijania się do świadomości": czy w końcu w tym nowym wątku, z tamtym opisem udało mi się wyjaśnić kilka kwestii i trafić do świadomości niektórych osób?
• a propos "tu chyba jest inny kanał": zakładam, że niektórzy po tym opisie z nowego wątku nie czują się już zagubieni i nie będą pisać o jakimś kanale i w domyśle o wpuszczaniu kogoś w kanał.
• a propos "trzeba (sobie) robić dobrze": róbmy dobrze, ale przede wszystkim miejmy na uwadze to jaki wpływ ma to co robimy na innych

Witam

Nie wiem dlaczego w edytorze Visual Sudio Code przy print wyświetla automatycznie litera na biało z dwoma kropkami.
Zauważyłem, że jak skopiuje kod z edytora i wkleję w notatniku, to znika białe litery np: x:
W miejsce print nie powinno wyświetlać litera na biało. Dlaczego tak się dzieje?

println(x:"Hello World ");  
print(s:"Please enter your name: ");

Na zdjęciu wygląda tak

@Dromer: i bardzo dobrze że się nie kopiuje. To nie jest część kodu tylko informacja na temat parametrów metody dodawana przez ide.

Poszukaj VS Code Inlay Hint

@opiszon

Ustawienie i wpisałem inlay hints
W edytorze tekstu zmieniłem na offUnlessPressed

Dziękuję za pomoc.

Na stronie CodeGym link jest możliwość kursu z Java i zarejestrowałem się. W trakcie nauki antywirus wykrył, że moje połączenie nie jest prywatne.

Cytuję: "Atakujący mogą próbować ukraść Twoje informacje z wiryny cick.adskeeper.co.uk (na przykład hasła, wiadomości lub karty kredytowe). NET::CERT_AUTHORITY_INVALID".

Po zarejestrowaniu nie wiedziałem, że kurs jest płatny i nie rozpakowałem prezentu. Po 24h od rejestracji za odblokowanie lekcji każą zapłacić za kurs i nazywają subskrypcją. Co ciekawe za miesięczną lekcje 129zł można płacić tylko kartą kredytową zamiast przelewu. Kurs z opcją na trzy miesięcy daje możliwości przelewu prawie 400zł.

Serwer jest z Wielkiej Brytanii, bo tak wykrył antywirus.

Przypomniało mi się, że moja kuzynka mieszka w Anglii i kupiła używanego laptopa z leasingu i włamali się. Z telewizora miała dostęp do pornografii. Musiała zmienić dostawcę internetu.

Czy strona CodeGym jest godna zaufania, pomimo, że wykrył antywirus? Na dowód umieściłem zdjęcie:

Jest luty 2024, czy Java dalej jest najbardziej opłacalnym językiem programowania na długie lata? Czytałem wiele opinii że Dart jest lepszą Javą, ma lepszą zwięzłą składnię i zarządzanie nullami z frameworkami Serverpod i Dart Frog. Duży wzrost w rankingach ma też TypeScript, stosowany też na backendzie z Node, Bun, Deno. Jest jeszcze Kotlin, C#, Go i to takie główne języki na rok 2024? Python wiadomo ale Django jakoś nie zawojowało backendem, dalej dominuje tu PHP z Laravelem. Kiedy pojawi się nowy ranking stackoverflow survey 2024? https://survey.stackoverflow.co/2023/
Możecie wymienić wasze top 5 technologii na 2024 rok w które warto inwestować swój czas?

Jest luty 2024, czy Java dalej jest najbardziej opłacalnym językiem programowania na długie lata? Czytałem wiele opinii że Dart jest lepszą Javą, ma lepszą zwięzłą składnię i zarządzanie nullami z frameworkami Serverpod i Dart Frog.

Według tego indeksu co podlinkowałeś (nie wiem jeszcze co tam mierzą) to Java ma 30.55% a Dart tylko 6.02%, za to Rust aż 13.05%, nawet Kotlin ma 9.06%

Moje prywatne rokowania na 2024 rok, nie wiem czy się sprawdzi.
Co może najbardziej wypierać Jave na backendzie. Myślę że Go, C# i Kotlin to jej główni najważniejsi rywale, może jeszcze dojść TypeScript na jakimś Bun lub Deno. https://deno.com/blog/deno-in-2023
C/C++ tutaj nic się nie zmienia rywalem jest tylko Rust.
Python chyba też nie ma rywali, jest R, Julia, jakieś Mojo i F# czy nawet Scala które się nie liczą.

Reasumując w przypadku Javy developerzy będą z czasem przechodzić do Kotlina, Go. Tak samo z C# mogą przejść do tych dwóch nowszych technologi.
Z JavaScript jest przejście na TypeScript.
PHP ma konkurentów w postaci Node JS/TS oraz Python z Django, Ruby on Rails raczej ludzie odchodzą.
Poza Kotlinem, Rust, TypeScript i Go nie ma za dużo nowości. Swift, Dart to mobile. Tutaj Kotlin jest też na mobile.
Python jest niezagrożony daleko za nim jest R, a Julia to już całkowicie na dole rankingu.

Ktoś się z tym zgadza co do tych najbardziej pożądanych języków na 2024 rok?
0 Python tu jest bez zmian w swojej kategorii.
1 Typescript
2 Go
3 Kotlin
4 Rust
5 Java lub C#

Go raczej nigdy nie zastapi javy, zupelnie inna filozofia stoi za tym jezykiem. Do tego jezeli chodzi o liczbe ofert pracy to jest kiepsko i od pewnego czasu nic sie nie zmienia.

Seken napisał(a):

Go raczej nigdy nie zastapi javy, zupelnie inna filozofia stoi za tym jezykiem. Do tego jezeli chodzi o liczbe ofert pracy to jest kiepsko i od pewnego czasu nic sie nie zmienia.

jak zupełnie inna?

Java to miał być prosty, obiektowy, statycznie typowany język programowania z bezpiecznym zarządzaniem pamięcią robionym przez GC i bez pułapek C++.

Go to miał być prosty obiektowy, zarządzany, statycznie typowany język programowania łatwe do nauczenia przez ludzi świeżo po studiach którzy przyszli pracować w Google.

Oba języki mają dość ciężki runtime, oba są oparte o polimorfizm czasu wykonania, oba mają kompilator nastawiony bardziej na szybkość kompilacji niż optymalizację i oba mają rozbudowaną bibliotekę standardową.

Największa różnica polega tylko na tym że Go kompiluje statyczne binarki w których już jest runtime a Java ma tradycyjnie osobny jvm.

Jak dla mnie to Go idealnie się wpisuje w wymagania stawiane początkowo Javie, zwłaszcza przed Javą 1.5. Nawet to uczucie bycia ograniczonym (Java: nie potrzebujesz przeciążania operatorów; Go: nie potrzebujesz genericsów) jest podobne.

Inna filozofia to stoi za Rustem: Możesz wszystko, damy Ci cały warsztat, każdy rodzaj młotka, tysiące bitów do śrubokrętów, łącznie z piłą elektryczną, obrabiarką CNC, prasą i drukarką 3D ale damy Ci odpowiednie narzędzia abyś nie zrobił sobie tym krzywdy (jdnak możesz nie używać - patrz unsafe).

Dla odmiany Java/Go: damy Ci plastikowy śrubokręt i drewniany młotek, powinno wystarczyć, poradzisz sobie.

C++: to samo co Rust ale zamiast osłony ostrza piły, okularów ochronnych i odpowiedniego ubrania jest tylko tabliczka “Uwaga! Niebezpieczeństwo” na ścianie.

Podstawowy problem jaki dostrzegam z Java jest to, że ów język jest rozmieniany na drobne przez wszelkie "bootcampy", "szkoły programowania", "weekendowe kursy". W obiegu też jest spora ilość zakamuflowanych juniorów z lat poprzednich którzy włożyli nogę w drzw. Absorbcja tego typu ludzi musi istnieć bo sensowni kandydaci z doświadczeniem mają na lokalnym rynku coraz trudniej.

Ponadto przygotowania do procesu rekrutacji na stanowiska gdzie w tytule jest Java stały się przemysłem. Pisanie cefałek, pisanie zadań rekrutacyjnych, refaktorowanie kodu "aby wyglądał, że to pisał mid", przygotowania do różnych testów. Dużo tego jest.

Z drugiej strony junior po szybkiej ścieżce pobędzie na rynku może trzy, może cztery lata aż dopadnie go/ją wypalenie zawodowe bo rozpoznawanie bojem jest w każdym przypadku bardzo kosztowne.

Krolik napisał(a):

Seken napisał(a):

Go raczej nigdy nie zastapi javy, zupelnie inna filozofia stoi za tym jezykiem. Do tego jezeli chodzi o liczbe ofert pracy to jest kiepsko i od pewnego czasu nic sie nie zmienia.

jak zupełnie inna?

Java to miał być prosty, obiektowy, statycznie typowany język programowania z bezpiecznym zarządzaniem pamięcią robionym przez GC i bez pułapek C++.

Na poczatku moze i tak bylo. Po latach mamy jezyk, ktory jest praktycznie zrosniety ze springiem i ciezko mowic o szybkim developmencie bez wykorzystania tego frameworka. W efekcie nie ma nawet co mowic o prostocie, bo 80% osob nie ma zielonego pojecia co sie dzieje i nazywa to "springowa magia". Owszem jest to kwestia frameworka, ale skoro jezyk nic z tym nie robil to najwidoczniej taka sytuacja jest w porzadku.

Go to miał być prosty obiektowy, zarządzany, statycznie typowany język programowania łatwe do nauczenia przez ludzi świeżo po studiach którzy przyszli pracować w Google.

No nie bardzo. Nawet tworcy jezyka w kwestii czy Go jest obiektowy mowia "to zalezy": https://go.dev/doc/faq#Is_Go_an_object-oriented_language
Mial sluzyc w googlu, ale nie tylko swiezakom, a po prostu usprawnic development, tak zeby kazdy byl w stanie rozumiec kod bez uprzedniej tygodniowej analizy wielkich systemow.

Oba języki mają dość ciężki runtime, oba są oparte o polimorfizm czasu wykonania, oba mają kompilator nastawiony bardziej na szybkość kompilacji niż optymalizację i oba mają rozbudowaną bibliotekę standardową.

Obydwa tez finalnie sa tlumaczne na jezyk maszynowy, no kto by sie spodziewal :D.

Jak dla mnie to Go idealnie się wpisuje w wymagania stawiane początkowo Javie, zwłaszcza przed Javą 1.5. Nawet to uczucie bycia ograniczonym (Java: nie potrzebujesz przeciążania operatorów; Go: nie potrzebujesz genericsów) jest podobne.

Java nadal nie pozwala przeciazac operator, a generyki w Go istnieja chyba od wersji 1.18 (prawie 2 lata temu).

Inna filozofia to stoi za Rustem: Możesz wszystko, damy Ci cały warsztat, każdy rodzaj młotka, tysiące bitów do śrubokrętów, łącznie z piłą elektryczną, obrabiarką CNC, prasą i drukarką 3D ale damy Ci odpowiednie narzędzia abyś nie zrobił sobie tym krzywdy (jdnak możesz nie używać - patrz unsafe).

Dla odmiany Java/Go: damy Ci plastikowy śrubokręt i drewniany młotek, powinno wystarczyć, poradzisz sobie.

To jest jakis belkot na ktory nawet nie umiem odpowiedziec.

Ktokolwiek pisal komercyjne systemy w tych jezykach doskonale rozumie roznice i nie uzywalby ich zamiennie, bo robienie wielu rzeczy w Go (np przetwarzanie danych) za pomoca raw loopow nie dosc, ze byloby masochistyczne to zajmowaloby 20 razy wiecej miejsca niz ekwiwalent w javowych streamach.

Za java stala prostota (ktorej juz nie ma), w przypadku Go mowimy o minimalizmie

@Królik To kochane google zwolniło w 2023 przeszło ponad 12 000 tys pracowników. W 2024 roku zwolniło ponad 1000 tysiąc pracowników, czyli tysiące pracowników straciło pracę i myślisz że oni teraz będą wspierać dalej języki Go i Dart czy ten Carbon. Nie, większość z nich już zasiliła szeregi innych technologii, Pythona, czy innych nowoczesnych języków programowania. Google ma ludzi za nic, zarabia na ich prywatność telemetrii (w co klikasz)z reklam w które klikają na youtube i w swoich wyszukiwarkach i przeglądarka. Google usunęło ponad 90% wyszukiwań ze swojej wyszukiwarki, nie można nic już znaleźć w porównaniu z rokiem 2008. Google powiedziało że można wyłączyć w swojej Chrome Browser i Chromium tego googlecasta i to nie prawda ludzie wyłączali tę funkcję przyciskami, flagami przeglądarki, a ona dalej działała w tle. Twórcą C i Go jest Ken Thompson nie Rob Pike.

https://businessinsider.com.pl/firmy/google-zwalnia-12-tys-osob-zatrudnialo-w-innej-rzeczywistosci-gospodarczej/768kb4f

https://cyberfeed.pl/google-potwierdza-ze-wlasnie-zwolnilo-okolo-tysiaca-pracownikow/

https://bulldogjob.pl/readme/programistow-go-czeka-niemile-zaskoczenie

https://www.techspot.com/news/80729-complete-list-alternatives-all-google-products.html

https://killedbygoogle.com/

Jako że dostąpiłem zaszczytu obcowania z Virtual Threads (aka Project Loom) to powiem wprost: Java kicks! I raczej długo jeszcze z nami zostanie.

Sama idea Virtual Threads jest genialna, piszesz kod synchroniczny który wykonuje się jak asynchroniczny. Działa to bardzo podobnie co do goroutines w Golang'u. Oczywiście są jeszcze pewne problemy np. pewne rodzaje locków blokują carrier thread'y (czyli wątki używane do faktycznego wykonywania tych wirtualnych) ale są na to obejścia (użycie ReentrantLock i innych prymitywów zamiast synchronized i wait/notify). Spring ma już pełne wsparcie do VT. Z pewnością poprawi to przepustowość niezliczonych aplikacji web'owych w Java, do tego takie rzeczy jak pule wątków czy executory mogą odejść do lamusa, VT są tanie i o ile nie trzeba throttle'ować jakichś obliczeń to można po prostu odpalić VT i niczym innym się nie przejmować. Nie wszystkie biblioteki wspierają jeszcze VT, ale po tym jak Spring wydał wersję ze wsparciem jest to już tyko kwestią czasu.

Poza tym hitem, miałem też okazję użyć ZGC. Koniec z długą listą parametrów i przełączników GC, zazwyczaj wszystko po prostu działa. Odświeca heap do TBów danych, tak tak twoja stara apka Javowa może teraz chodzić na heapie z 16TB RAM i GC to łyknie. Do tego udało im się zminimalizować pauzy, to co trwało 20ms teraz często wykonuje się <2ms.

Najnowsze JDK znacznie poprawia też wydajność. Osobiście w ciągu 2023 miałem przyjemność pracować ze starym 1.8 oraz nowszymi 11, 17 i ostatnio 21! Tępo zmian jest denerwujące, ale przynajmniej widać że Java nie stoi w miejscu!

A teraz odpowiem na postawione na autora pytanie: Co dalej?
Java oczywiście!