[nad__czlowiek]

#programowanie #programista15k #programista25k #programista30k #java #javascript #pracait

Ej wytłumaczcie mi jedno - czemu za każdym razem jak programiści Sun/Oracle robili coś w wawce to biblioteki i frameworki tworzone przez community zazwyczaj są lepsze?

1. Spring >>> Java EE aka obecnie Jakarta EE (swoją drogą czemu to gówno nie chce zdechnąć xDD) [tak wiem, spring obecnie nie ma nic wspólnego z "lightweight" i stał się podobną kobyłą co Java EE kiedyś)
2. VAVR.IO >>> Java 8 streams
3. Guava/apache collections >>> Java collections
4. Teraz ludzie piszą, że "virtual threads" to będzie rewelacja i zaora frameworki i biblioteki zwłaszcza reaktywny Web Flux xD No chyba coś znowu nie wyszło programistom Oracla ( ͡°( ͡° ͜ʖ( ͡° ͜ʖ ͡°)ʖ ͡°) ͡°)

Oczywiście, Spring WebFlux to zawsze była opcjonalna ścieżka, bo jakieś popularne (przynajmniej w naszym kraju) to to nie jest. I tak, większość developerów już pewnie #!$%@? 2-3h po godzinach ucząc się wątków virtualncyh, bo świat na spring-web developerce się nie kończy. Aczkolwiek gdy firma będize poszukiwać performace... to i tak wybierze web-fluxa a nie jakieś śmieszne virtual threadsy xDDD

https://medium.com/deno-the-complete-reference/springboot-virtual-threads-vs-webflux-performance-comparison-for-jwt-verify-and-mysql-query-ff94cf251c2c

[Saly]

Spring >>> Java EE

@nad__czlowiek: spring jest nowszy. Wczesny spring też mocno się różnił w porównaniu do tego jest teraz.

VAVR.IO >>> Java 8 streams

@nad__czlowiek: vavr to zupełnie nowy rodzaj kolekcji. Java była projektowana jako język imperatywny z mutowalnymi kolekcjami i streamy to dobry dodatek do już istniejący klocków

3. Guava/apache collections >>> Java collections

@nad__czlowiek: biblioteka standardowa ma ten problem, że nie może za dużo dodawać, bo

[Saly]

Aczkolwiek gdy firma będize poszukiwać performace... to i tak wybierze web-fluxa a nie jakieś śmieszne virtual threadsy xDDD

@nad__czlowiek: nie, z czasem virtual thready będą wydajniejsze (bo streamy nie zapewniają niczego poza abstrakcją) i webflux będzie używany tylko w przypadkach, gdy ktoś uzna, że model reaktywny ma sens w danej aplikacji. W normalnej apce nie ma takiej potrzeby, bo typowy CRUD dla typowego endpoinu chce coś pobrać z bazy, zawołać parę

[LazyInitializationException]

@nad__czlowiek: Tym wpisem pokazujesz, że nie wiesz o czym mówisz xd

[Kresse]

@nad__czlowiek: Największym problemem Javy jest kompatybilność wsteczna, która bardzo ogranicza innowacje. Z drugiej strony jest to też jej duży plus ¯\(ツ)/¯

[e.....s]

@nad__czlowiek: podobają mi się Twoje wpisy ( ͡° ͜ʖ ͡°)

[Krolik]

Większość ludzi (patrz go) chce szybkiego IO i green thready to umożliwiają.

@Saly: Green thready nie są w niczym szybsze od wątków systemowych, a w szczególności nie robią szybciej I/O, bo mają dodakowy narzut na mapowanie wątków Javy do wątków systemowych, a samo I/O w jednym i drugim przypadku wymaga przełączenia kontekstu na systemowy. Ponadto I/O blokujące jest starsze i wydajniejsze (lepiej zoptymalizowane) niż asynchroniczne na większości systemów (paradoksalnie nawet iouring

[Saly]

Green thready nie są w niczym szybsze od wątków systemowych

@Krolik: czytałem, że context switch natywnych wątków jest dosć kosztowny, pamięć to na pewno największy plus

Green thready kosztują znacznie mniej pamięci niż wątki systemowe dlatego są lepszym rozwiązaniem jeśli potrzebujesz obsługiwać ponad 10 tys. połączeń

@Krolik: dla mnie zawsze główną motywacją było możliwość użycia asynchronicznego io w sposób synchroniczny. Green thready pozwalają na użycie takich zabawek jak epoll minimalizujących

[Krolik]

czytałem, że context switch natywnych wątków jest dosć kosztowny

@Saly: problem w tym, że jeśli robisz I/O to niezależnie od sposobu realizacji współbieżności ten context switch do systemu musisz zrobić. Inna sprawa że z tym "dość kosztowny" to znowu nie tak bardzo - kilkaset nanosekund do max kilku mikrosekund, to raptem tyle co zrobisz parę alokacji na heapie w Javie i już masz porównywalny koszt ;) Gamechangerem w tej kwestii ponoć

[Saly]

problem w tym, że jeśli robisz I/O to niezależnie od sposobu realizacji współbieżności ten context switch do systemu musisz zrobić.

@Krolik: tak, ale zbiórczo dla wszystkich operacji IO. epoll_wait czeka aż pojawi się cokolwiek przez co czas trwania takiego syscalla jest dużo krótszy (bo czekamy na cokolwiek a nie na określoną akcję). Przy jednowątkowym reaktorze masz jeden wątek, który woła epoll_wait, gdzie w takim tradycyjnym podejściu mam N wątków czekających

[pabisbar]

@nad__czlowiek: Ten benchmark został źle przeprowadzony. Użyto w nim JDBC Driver który ma w implementacji dużo bloków synchronized i to w krytycznych momentach. Przez to VTs wypadły jak widać w tabelach, ponieważ MySQL Connector je blokował. Test powinien zostać przeprowadzony z użyciem ReentrantLock który jest VTs friendly. Pozostałe benchmarki które widziałem stawiały VTs na równie z WebFluxem w codziennym użyciu.

[nad__czlowiek]

@pabisbar: no to trzeba będzie trochę poczekać, bo zazwyczaj każda biblioteka connectora bazy danych ma własną obsługę współbieżności

[Krolik]

@Saly: ale po wywolaniu epoll musisz jeszcze odczytać / zapisać dane. Czyli musisz zrobić read/write i tu masz drugi context switch. W tradycyjnym podejściu masz tylko read/write blokujące - więc masz tych przełączeń mniej.

[biaukowe]

@Krolik: ile zarabiasz netto?

[Krolik]

@biaukowe: a co Cię to obchodzi? Nie podaje takich danych bo po pierwsze umowa zabrania podawania takich danych publicznie, po drugie zaraz by się zleciały trolle i wrzucały teksty w stylu "a potem się obudziłeś, wstawaj bo spóźnisz się do szkoły itp".

[biaukowe]

@Krolik: nie zesraj się tylko.

[Krolik]

@biaukowe: potwierdzasz, co napisałem :P