Přechod PHP -> Java

[Idris]

Bohuzel tam zas bude tvuj nejhorsi nepritel garbage collector a posleze neefektivita java jazyka

V reálně nasazovaných knihovnách se právě kvůli neefektivnímu GC zcela nepokrytě (ale skrytě) alokuje ručně, všechny velké frameworky volají skrytá (a nativní, tedy “unsafe”) API, aby se vyhnuly enormní režii GC. Na obranu autorů Javy je třeba dodat, že tracing GC nejde udělat efektivně, i kvalitní a promyšlené implementace (konzervativní GC s nízkou latencí) mají v některých typech úloh problémy s efektivitou.

[Reklama]

[redustin]

Bohuzel tam zas bude tvuj nejhorsi nepritel garbage collector a posleze neefektivita java jazyka - jako napr. boxovane typy.

To je pravda. Na druhou stranu se java stále vyvíjí a i legacy projekty mají poměrně vysokou šanci, že v blízké budoucnosti budou mít k dispozici low-latency GC https://wiki.openjdk.java.net/display/zgc/Main a v mírně vzdálenější budoucnosti hodnotové typy a primitivní typy v kolekcích https://wiki.openjdk.java.net/display/valhalla/Valhalla_Goals . Velký projekt, ale dělá se na něm celkem dost http://hg.openjdk.java.net/valhalla/valhalla .

Ani dnes bych se nebál postavit nový projekt na javě.

[nula]

Bohuzel tam zas bude tvuj nejhorsi nepritel garbage collector a posleze neefektivita java jazyka

V reálně nasazovaných knihovnách se právě kvůli neefektivnímu GC zcela nepokrytě (ale skrytě) alokuje ručně, všechny velké frameworky volají skrytá (a nativní, tedy “unsafe”) API, aby se vyhnuly enormní režii GC. Na obranu autorů Javy je třeba dodat, že tracing GC nejde udělat efektivně, i kvalitní a promyšlené implementace (konzervativní GC s nízkou latencí) mají v některých typech úloh problémy s efektivitou.

Jj, presne tak. Bohuzel to byva problematicke, protoze Oracle tomu hazi klacky pod nohy a meni unsafe api pod rukama (i kdyz teda samozrejme nikdo nikdy negarantoval, ze zustane stejne, ale z praktickych duvodu se kod velkych frameworku unsafem jenom hemzi - jinak to rozumne delat neslo).

[Idris]

Bohuzel tam zas bude tvuj nejhorsi nepritel garbage collector a posleze neefektivita java jazyka

V reálně nasazovaných knihovnách se právě kvůli neefektivnímu GC zcela nepokrytě (ale skrytě) alokuje ručně, všechny velké frameworky volají skrytá (a nativní, tedy “unsafe”) API, aby se vyhnuly enormní režii GC. Na obranu autorů Javy je třeba dodat, že tracing GC nejde udělat efektivně, i kvalitní a promyšlené implementace (konzervativní GC s nízkou latencí) mají v některých typech úloh problémy s efektivitou.

Jj, presne tak. Bohuzel to byva problematicke, protoze Oracle tomu hazi klacky pod nohy a meni unsafe api pod rukama (i kdyz teda samozrejme nikdo nikdy negarantoval, ze zustane stejne, ale z praktickych duvodu se kod velkych frameworku unsafem jenom hemzi - jinak to rozumne delat neslo).

Oracle jen ještě víc podělal už tak dost stupidní situaci.

[kimec]

Odporucam vam Javu. Vyhoda Javy je, ze sa pouziva napriec roznymi odvetviami: od ultra low latency systemov na financnych burzach az po klasicke korporaty, banky, IoT, BigData a ML. Mate velky pool moznosti a mozete sa presuvat medzi roznymi odvetviami, ked vas nieco omrzi.

Ak chete mat aj "vzruso" aj cas na dieta a stabilne platit hypoteku, Java je dost dobra volba.

Se zbytkem souhlasim, ale ultra low latency? Jako vazne? To jsem jeste nevidel. Pokud se jedna o ms, tak je to asi egal, ale kdyz je treba fungovat v μs a spolehlive, tak se mi to nejak nezda.

U BigData se pouziva, protoze je velky a funkcni a ekosystem. Z velke casti i free. Bohuzel tam zas bude tvuj nejhorsi nepritel garbage collector a posleze neefektivita java jazyka - jako napr. boxovane typy. Tezko rict, jestli casem toto neprebere Rust. I kdyz bez ekosystemu tezko.

Rozumiem vasmu prekvapeniu, ale je to tak. Nerozumiem preco by Java nemohla "fungovat spolehlive v μs".

Java postupne nahradza C++ v ultra low latency domene, kvoli "time to market", transparentnosti a debugovatelnosti.
Je pravdepodobne, ze v C++ sa da napisat rychlejsi kod, ale za cas, ktory budete tunit C++, iny tim doda fungujuce riesenie v Jave, ktore bude porovnatelne rychle ako neoptimalizovane C++ a vyfukne vam potencialny naskok na trhu.

Je to cisto ekonomicky problem: ani C++ ani Java neporazi FPGA a ASIC. A teda ak chcem nieco super rychle, tak to nebudem robit v C++ alebo v Jave, ale rovno FPGA. Pokial som bohaty, urobim si batch ASICov.

Samozrejme, ultra low latency Java nie je idiomaticka Java, ktora sa pise v klasickych korporatoch. Tu sa bavime o tom, ze mi zalezi na NUMA, cachiach, forme synchronizacie, pinovanie trheadov, OS tunning, GC tuning (resp. no GC), busy spinovanie atd.

Ak ste sa o tuto domenu nikdy nezaujimali, odporucam vam prednasku: Ultra low latency Java in the real world - Daniel Shaya

[Reklama]

[kimec]

Bohuzel tam zas bude tvuj nejhorsi nepritel garbage collector a posleze neefektivita java jazyka - jako napr. boxovane typy.

To je pravda. Na druhou stranu se java stále vyvíjí a i legacy projekty mají poměrně vysokou šanci, že v blízké budoucnosti budou mít k dispozici low-latency GC https://wiki.openjdk.java.net/display/zgc/Main a v mírně vzdálenější budoucnosti hodnotové typy a primitivní typy v kolekcích https://wiki.openjdk.java.net/display/valhalla/Valhalla_Goals . Velký projekt, ale dělá se na něm celkem dost http://hg.openjdk.java.net/valhalla/valhalla .

Ani dnes bych se nebál postavit nový projekt na javě.

Kazdy tracing GC (a teda aj ZGC) ma zasek, ide o to, ako dlho zasek trva a ci dlzka zaseku je proporcna velkosti heapu. Low latency system by z pravidla nemal mat zasek ziaden. Tu je ale zase ina otazka a to, co sa vlastne za zasek povazuje, nakolko aj OS samotny ma rozne zaseky. Odporucam clanok o coordinated omission. Kazdopane, ZGC je lepsie oznacit za low pause GC. Podobne ako Shenandoah.

Aj "pause-less" GC ako C4 v Zingu ma malicku pauzu, akurat je ta pauza taka kratka, ze zaseky sposobene kernelom a OS samotnym su vacsie. Btw prave ZGC je velmi podobne C4 v Zingu. Bola okolo toho aj "mala drama". Mne osobne sa viac paci Shenandoah nakolko neni od Oracle ale od overeneho opensource vendora.

[gill]

Moderni PHP pri zapnutem strictu a typehintama a Laravelem je uz rozumne pouzitelna zalezitost.

Je to defacto opajcovany Spring boot, maven se jmenuje composer. Templatovane pres blade a bootstrap

Delal jsem ted v tom nejake udelatka, jazyk byl dan zadavatelem.
A slo to celkem s vyuzitim VS Code rozumne pouzivat, rozhodne lip, nez treba Go.

jestli se vám líbí Java, nedivím se, že se vám líbí i moderní PHP.

[fortran1986]

Moderni PHP pri zapnutem strictu a typehintama a Laravelem je uz rozumne pouzitelna zalezitost.

Je to defacto opajcovany Spring boot, maven se jmenuje composer. Templatovane pres blade a bootstrap

Delal jsem ted v tom nejake udelatka, jazyk byl dan zadavatelem.
A slo to celkem s vyuzitim VS Code rozumne pouzivat, rozhodne lip, nez treba Go.

Ale stále ten skript beží len pár sekúnd po requeste. V iných prostrediach si viem zvoliť dobu platnosti objektu. V PHP je platnosť objektu max. per-request. Pri ďalšom requeste sa vymaže celý obsah pamate a skript beží "nanovo". A dokonca aj ten beh skriptu zvykne byť časovo obmedzený (podľa nastavení). Odpoveďou na request je vždy nejaký string pričom PHP skript rieši len spracovanie vstupu na základe ktorého generuje nejaký textový výstup. Je to teda taký lepší templating engine povýšený na jazyk.

PS: neberte to ako hejt ja tiež na niektoré menšie veci používam PHP.

[Kit]

Ale stále ten skript beží len pár sekúnd po requeste. V iných prostrediach si viem zvoliť dobu platnosti objektu. V PHP je platnosť objektu max. per-request. Pri ďalšom requeste sa vymaže celý obsah pamate a skript beží "nanovo". A dokonca aj ten beh skriptu zvykne byť časovo obmedzený (podľa nastavení). Odpoveďou na request je vždy nejaký string pričom PHP skript rieši len spracovanie vstupu na základe ktorého generuje nejaký textový výstup. Je to teda taký lepší templating engine povýšený na jazyk.

To je přesně účel PHP. Sice jsem veškeré HTML vystrnadil mimo něj, ale stále je to jazyk, ve kterém zpracuji vstup, provedu interakci s databází, vyleju data na výstup a ukončím skript. Není to pár sekund, ale jen desítky milisekund. Paměť se promázne a může zpracovat další request. Nemusím řešit memory leaky, synchronizaci vláken a když proces jednoho requestu spadne, na další to nemá vliv. Zero down time při update je také velkou výhodou, kterou se každý jazyk pochlubit nemůže.