Wpisy z tagiem: java

@Afish: CompletableFuture z timeoutem chyba by trochę jednak pomogło ;)

@Shalom: A CompletableFuture nie zablokuje Ci wątku na zwykłym blokującym zapisie? Bo jak tak, to masz zagłodzenie przy dużym obciążeniu.

@Dzikoysk: ja tam ciągle spotykam kotlinowców zachwyconych korutynami (w androidzie na pewno). Korutyn nie lubię - głównie za zmarnowany potencjał - można było zrobić async dobrze, a wybrali ograniczoną i w sumie męczącą w użyciu implementację.

Ja szanuję za starania, ale jakby rozumiem czemu można ich nie lubić. Imo chyba największy problem, to że próbują adresować kilka kwestii na raz i ostatecznie nie dowieźli tego w za dobrej formie. Z jednej strony mogli napisać kolejny wrapper na reactive streamy na poziomie składni, a z drugiej poszli dalej i spróbowali imitacji fiberów. To by było nawet spoko, ale gdyby jasno ograniczyli się do kodu faktycznie działającego w tym ekosystemie (czyli stricte dedykowane std i libki które mogą zostać tylko na tym zbudowane), bo dodanie do tego compatibility z Javą i innego niereaktywnego API trochę robi z tego magic boxa i powrót do zabawy z weryfikacją integralności apki w runtime, a nie na poziomie kompilatora. No nic, na pewno jest to kolejny stymulant do tego by w ogóle o myśleć o takich rzeczach w Javie, szkoda że niestety wychodzi z tego rozwiązanie pośrednie na drodze tej ewolucji, a nie jakiś faktycznie fajny finalny produkt.

"Czy głównym celem tych benchmarków jest konfudowanie ludzi?" Można przeczytać w History jaki był cel pierwszego autora (porównanie języków skryptowych). Jaki jest aktualny cel teraz to ja nie wiem :D "może są one po to, żeby programistom nie było zbyt nudno i żeby mogli się spuszczać nad swoim ulubionym językiem." Jak ktoś się spuszcza nad językiem programowania to jego sprawa. Jakbym chciał spuszczać sie nad tym jaki mój ulubiony język jest szybki to zacząłbym pisać w Ruscie :D Ani Java, ani Haskell nie trafią pewnie nigdy na podium najszybszych języków programowania. A jeśli trafią to będzie to pewnie inna Java lub inny Haskell niż znamy dziś (Z o wiele większą ilością niskopoziomowego kodu) :D Chyba za mało śmiejących się buziek dałem wtym wpisie żeby ludzie się zorientowali że nie traktuję tego porównania całkowicie serio :D Zwłaszcza jak różnica między niektórymi językami jest tak mała i w przeciągu roku jest przeskok OCamla o co 4 miejsca :D

Free Pascal ma już lepszą efektywność niż C++ — i to mi odpowiada. ;)
Chociaż ciul wie, nie umiem czytać tego wykresu.

@0xmarcin: jedna rzecz, która stale kuleje w ostatnich latach to javafx. Co różna wersja i dostawca JDK to co innego w JavaFX nie działa. Fakt, że to dość niszowa technologia i chyba wszyscy istotni gracze już ją olali.

@jarekr000000: dlatego samo JavaFX zaleca generowanie całych obrazów aplikacji, w JDK 16 jest to bezproblemowe i działa dla Win/Lin/macOS (mam parę takich projektów na GH). O ile wszystkie biblioteki zależne używają JPMS to bułka z masłem. Bez JPMS trzeba się trochę napocić. Jedyn problem z takim podejściem jest taki że aktualizacja JDK == aktualizacja aplikacji, a JDK ma łatki security dosyć często...

@Aventus: Pan poczeka. Programiście .net nie mają dużej ilości problemów przez to, że często mają jedyną słuszną implementacje problemu X.

Dałem gwiazdkę. Co ciekawe kiedyś próbowałem zrobić kontener z obsługą generyków (czyli symulacją generyków tak żeby dało się resolvovać np. CommandHandler<FooCommand> i to jest masakra. Poległem na tym zupełnie, w C# nie mają takich problemów tam to po prostu działa. Abstrahując od mojej uwagi, fajny projekt.