Köszi! Most nem tudok videózni, de meg fogom nézni, kiváncsi vagyok.
Érdekes egyébként, hogy amikor egyetemre jártam, akkor óriási hájpja volt a Javának, illetve az XML-nek. Emlékszem, hogy mondták, hogy a Javának mennyire kicsi az overheadje, és az ugye ordó konstans, ha viszont hatékony adatszerkezeteket használunk, akkor pikk-pakk gyorsabb lesz, vagy nagyjából ugyanolyan gyors, de gyorsabban lehet elkészülni vele és megéri. Ez szerintem nagyjából bejött, de például a GraalVM, ami Ahead of Time fordít, az csak az utóbbi években lett mainstream. Meg a bármikor jövő GC is megmaradó probléma, illetve, hogy egy jókora infrastruktúra kell mire egyáltalán elindul a program.
A szoftverfejlesztés egyik csapdája a bonyolultság, az elszálló fejlesztési idő, és tényleg az van, hogy amivel a legjobban kezelhetővé válik ez a probléma, az a legjobb eszköz. Én például ezért hiszek a statikusan típusos nyelvekben, szerintem ha már nem tudjuk fejben tartani, hogy mit hogy hívnak pontosan, akkor rémálommá válik a típus nélküli fejlesztés. Illetve egy rakás dolgot tesztekkel kell biztosítani, amit a típusosság automatikusan ad. A Javát a mai napig jó választásnak érzem ha nincsen semmilyen specifikus igény (pl real time, bare metal, stb) ami miatt nem jó. (Ha jól emlékszem te a JVM-re épülő modernebb dolgokat is használod, sajnos azokkal nincs tapasztalatom.)
Vagy mondták például annó, hogy ha tömöríted, akkor az XML nem lesz nagyobb mint a bináris ábrázolás és nem is éri meg binárisozni. Na, olyan már volt a praxisomban, hogy egy XML helyett binárisat csináltunk, mert meg lehetett spórolni vele vagy 10 másodpercet és ott akkor ez már számított. A feldolgozás ideje nagyon nem kevés, és sok helyen ez igenis számít. Érdekes egyébként, hogy az általam ismert Java API-k mind új string objektumot gyártanak minden tagből, ami jókora overheaddé válik egy bizonyos méret felett. Ugye az UTF parszolás is hatalmas overhead, pedig ha mondjuk számok vannak az XML-ben, akkor teljesen felesleges volna objektíve, ASCII-ben is lehetne csinálni mindent. Szerintem ilyen no-copy, no instantiation trükkökkel jócskán lehetne a Java XML implementációkon javítani, de ugye akkor teljesen új API-t kellene létrehozni. (El tudom képzelni, hogy ma már van ilyen, nem vagyok naprakész, ha valaki ismeri linkelje!) Szóval az XML szerintem nem hozta azt amit ígértek, nem elég hatékony ahhoz, hogy mindenhol ez legyen a adatcsere formátum. Nem véletlenül burjánzanak a protobuff-jellegű megoldások. Méret prefix, bináris ábrázolás és RAM olvasás sebességgel lehet parszolni! Nagyon nem mindegy! De ahol nincs komoly teljesítmény igény, ott teljesen jó az XML/JSON is, és tényleg jó, hogy ránézésre érthető.
Szerk.: megnéztem, tényleg jó. Még egyszer köszi! Szerk2.: A Zig hihetetlen mértékben nyert a videó szerint. Belepörgettem a kommentekbe, és sokan mérési módszertani hibára gyanakszanak. Szóval ezt ki kellene rendesen elemezni, hogy mi is történt valójában. Számomra meglepetés, hogy a Rust is lenyomta a C-t, de az olyan hihetőbb mértékben, hogy az validnak tűnhet elsőre.