Ideálny programovací jazyk

[Zabanovaný Anonymní Troll]

Ze se ale za tu RAM vzdycky tolik plati, kdyz si nekde porizujes virtualni server. Porovnej treba hostingy PHP vs Java No nevim nevim, do jake miry to porekadlo s vykonem a ram plati.

Ja jeste doted zadny svuj virtualni server nemam - protoze delam v Jave a stalo by me to tak moc penez, si neco jen tak ze srandy koupit...

Kdybych delal v PHP, tak mam hosting lusknutim prstu, protoze to stoji par slupek.

Prosimtě ty děláš jakoby to byly nějaký horentní sumy a jako kdyby java automaticky žrala nějaký giga. Virtuál s 2GB RAM stojí asi 1500kč/rok (to jsou 2 hodiny programátora). Já na tom provozuju web, mysql a java server, na který je připojeno několik set klientů, momentálně celý systém žere 375MB RAM.

No, ono 100x nic zabilo vola. Ja si myslim, ze na vykonu a zravosti zalezi. Je to o tech detailech. Dam dalsi priklad - jak dlouho startuje Spring, treba pri JUnit springovych testech? To vsechno tak nejak s tou zravosti Javy souvisi.

A kde ti to stoji 1500,- za rok? U active24 je VPS 2GB za 400,- mesic, mel jsem VPS u Forpsi, tam jsem mel jen 1GB a stalo to pulku. Tak to by me zajimalo, kde jsi narazil na takovy kauf - 2gb jen za 1500,-. Moc ti neverim.

[Reklama]

[linuxak]

Optimalizované počítání referencí bývá efektivnější, jednak se nic nepočítá, když čítač nepřekročí 1 (objekty s krátkou životností, obdoba nejnižší generace v tracing GC), a za druhé statická analýza odhalí případy, kdy není nutné čítač upravovat, i když by to dávalo smysl, například při návratu z funkce, kde se typicky dělá retain a následný (auto)release hned po sobě, což překladač odhalí a vyhodí. Kupříkladu Swift takto funguje a je to efektivnější než tracing GC. C++ má úplně jiný přístup s move sémantikou, ale to už tu psali jiní.

Velkou režii má shared_ptr v C++ kvůli thread-safe control bloku, to vyžaduje synchronizaci mezi jádry při každé změně čítače. Přitom je to úplně zbytečné dělat, pokud instanci shared_ptr používá jen jeden thread. Thread-unsafe shared_ptr s nižší režií ve standardní knihovně C++ není. Myslím, že je to škoda a měla by být možnost volby, třeba Rust má obě varianty, Rc a Arc.

[Filip Jirsák]

Dam dalsi priklad - jak dlouho startuje Spring, treba pri JUnit springovych testech? To vsechno tak nejak s tou zravosti Javy souvisi.

Jak dlouho startují JUnit testy bez Springu? Jak dlouho startuje Micronaut? To je nějaká jiná Java?

[Zabanovaný Anonymní Troll]

Dam dalsi priklad - jak dlouho startuje Spring, treba pri JUnit springovych testech? To vsechno tak nejak s tou zravosti Javy souvisi.

Jak dlouho startují JUnit testy bez Springu?

Dost dlouho, na to ze je to jenom takovy psouk :-) A kdyz je tech psouku 1000 (Spring), tak uz to jde i dost videt. Proc to vubec resime toto. Kazdy proste vime, ze Java je pomala a nenazrana, pomalu startuje, v provnani treba s Go, nebo Swift, nebo Objective-C.

[KarelI KarelI]

Ze se ale za tu RAM vzdycky tolik plati, kdyz si nekde porizujes virtualni server. Porovnej treba hostingy PHP vs Java No nevim nevim, do jake miry to porekadlo s vykonem a ram plati.

Ja jeste doted zadny svuj virtualni server nemam - protoze delam v Jave a stalo by me to tak moc penez, si neco jen tak ze srandy koupit...

Kdybych delal v PHP, tak mam hosting lusknutim prstu, protoze to stoji par slupek.

Prosimtě ty děláš jakoby to byly nějaký horentní sumy a jako kdyby java automaticky žrala nějaký giga. Virtuál s 2GB RAM stojí asi 1500kč/rok (to jsou 2 hodiny programátora). Já na tom provozuju web, mysql a java server, na který je připojeno několik set klientů, momentálně celý systém žere 375MB RAM.

No, ono 100x nic zabilo vola. Ja si myslim, ze na vykonu a zravosti zalezi. Je to o tech detailech. Dam dalsi priklad - jak dlouho startuje Spring, treba pri JUnit springovych testech? To vsechno tak nejak s tou zravosti Javy souvisi.

A kde ti to stoji 1500,- za rok? U active24 je VPS 2GB za 400,- mesic, mel jsem VPS u Forpsi, tam jsem mel jen 1GB a stalo to pulku. Tak to by me zajimalo, kde jsi narazil na takovy kauf - 2gb jen za 1500,-. Moc ti neverim.

Nevím, spring nepoužívám. A pokud to je líný, tak tím spíš to nepoužiju.

Virtuál mám u Wedosu. V akci to bývá nějakých 800 ročně, jinak kolem těch 1500.

[Reklama]

[Filip Jirsák]

Proc to vubec resime toto. Kazdy proste vime, ze Java je pomala a nenazrana, pomalu startuje, v provnani treba s Go, nebo Swift, nebo Objective-C.

Ne, to „víte“ jenom vy. A řešíme to proto, abyste se dozvěděl, jak je to doopravdy. Když provedení aplikace v Go trvá průměrně 260 ms a doba běhu aplikace (s tím samým algoritmem) v Javě trvá průměrně 166 ms, nevypadá to, že by Java byla v porovnání s Go pomalejší. Spíš to vypadá opačně.

[kimec]

Dost dlouho, na to ze je to jenom takovy psouk :-) A kdyz je tech psouku 1000 (Spring), tak uz to jde i dost videt. Proc to vubec resime toto. Kazdy proste vime, ze Java je pomala a nenazrana, pomalu startuje, v provnani treba s Go, nebo Swift, nebo Objective-C.

Zrovna Spring nie je dokazom toho, ze Java je pomala. Keby bolo mozne Spring sprasit aj s tym masivnym znasilnovanim reflexie, ako to len on vie, v akomkolvek jazyku, bolo by to rovnako pomale...a nenazrane.

Mne sa napriklad dost paci novy hybridny pamatovy model, ktory do Javy pribudol. Zneuzitie TLABov na region based memory model, z toho plynuce znizenie pamatovych narokov, z toho plynuca GC-less dealokacia, nezavisle heapy, automaticka multitenancy, milisekundovy startup time... lahka integracia s C/C++. ved to je vsetko super, nie? Nechapem preco sa ludia z toho netesia.

[Cikáda]

Když více polygonů vlastní jeden node, tak ho nemůžou mít přes unique, to je v rozporu.
Když tam budu dávat obyčejný pointer, tak si musím někde počítat reference, což je ještě horší než sharedptr.
GC to dělá mnohem efektivněji, v tom je ten vtip a to se tady už od včerejška snažím říci. Stručně řečeno, nepočítá reference, chodí jen po přeživších a má výraznou “množstevní slevu”.

Pokud více polygonů vlastní jeden node, tak už nejsou jeho, ale všech. Tj. to úplně neodpovídá tomu, co jsi na začátku psal. Takže ano, pak není shared_ptr od věci. Nebo se to taky dá udělat tak, jak jsem psal předtím - vlastnit to bude nějaká nadstruktura nad tím, která to v případě potřeby uklidí.
S tou efektivitou GC bych byl opatrný, protože hodně také záleží, jak funguje vevnitř. V čem přesně myslíš, že má "množstevní slevu"?

Když to bude vlastnit nadstruktura, tak jak pozná, že může vyhodit nepoužívané nody? Jasně, řešení známe, ptám se spíš proto aby sis rozmyslel, jestli to opravdu dovedeš řešit lépe než těmi sdílenými pointery.

Tak tam záleží, jak to bude navrhnuto. Ale typicky přes counter, nebo nějaký vektor. Myslím, že rychlostně by si člověk mohl pomoct.

Typický GC má "množstevní slevu" proto, že se nestará o nedosažitelné objekty, řeší jen živé. To znamená, že čím déle vydrží neběžet, tím víc bude těch mrtvých a tím víc na tom ušetří. V důsledku toho je velmi levné dělat krátce žijící objekty, což má spoustu dalších pozitivních důsledků. Naopak new/delete se poctivě stará o každý objekt, což je dost neefektivní a v důsledku nutí programátora, aby se krátkodobým objektům vyhnul.

Jak se stará jen o živé? Ten overhead u GC nevadí? A proč by v C++ mělo být velmi drahé dělat krátce žijící objekty? Copak si nemůžu naalokovat paměť, kterou pak budu předávat, abych nemusel pořád alokovat a dealokovat?

Kdysi jsem si potřeboval ověřit, jak moc v javě můžu prasit a bezohledně alokovat nové a vyšlo mi, že má asi desetinásobnou průchodnost proti MS C++. Čili za daný čas dokáže alokovat a zahodit 10x víc objektů než C++.

Tak zrovna MS C++ není úplně vypovídající. Také by mě zajímalo, jak jsi to měřil.

[KarelI KarelI]

Když více polygonů vlastní jeden node, tak ho nemůžou mít přes unique, to je v rozporu.
Když tam budu dávat obyčejný pointer, tak si musím někde počítat reference, což je ještě horší než sharedptr.
GC to dělá mnohem efektivněji, v tom je ten vtip a to se tady už od včerejška snažím říci. Stručně řečeno, nepočítá reference, chodí jen po přeživších a má výraznou “množstevní slevu”.

Pokud více polygonů vlastní jeden node, tak už nejsou jeho, ale všech. Tj. to úplně neodpovídá tomu, co jsi na začátku psal. Takže ano, pak není shared_ptr od věci. Nebo se to taky dá udělat tak, jak jsem psal předtím - vlastnit to bude nějaká nadstruktura nad tím, která to v případě potřeby uklidí.
S tou efektivitou GC bych byl opatrný, protože hodně také záleží, jak funguje vevnitř. V čem přesně myslíš, že má "množstevní slevu"?

Když to bude vlastnit nadstruktura, tak jak pozná, že může vyhodit nepoužívané nody? Jasně, řešení známe, ptám se spíš proto aby sis rozmyslel, jestli to opravdu dovedeš řešit lépe než těmi sdílenými pointery.

Tak tam záleží, jak to bude navrhnuto. Ale typicky přes counter, nebo nějaký vektor. Myslím, že rychlostně by si člověk mohl pomoct.

Typický GC má "množstevní slevu" proto, že se nestará o nedosažitelné objekty, řeší jen živé. To znamená, že čím déle vydrží neběžet, tím víc bude těch mrtvých a tím víc na tom ušetří. V důsledku toho je velmi levné dělat krátce žijící objekty, což má spoustu dalších pozitivních důsledků. Naopak new/delete se poctivě stará o každý objekt, což je dost neefektivní a v důsledku nutí programátora, aby se krátkodobým objektům vyhnul.

Jak se stará jen o živé? Ten overhead u GC nevadí? A proč by v C++ mělo být velmi drahé dělat krátce žijící objekty? Copak si nemůžu naalokovat paměť, kterou pak budu předávat, abych nemusel pořád alokovat a dealokovat?

Kdysi jsem si potřeboval ověřit, jak moc v javě můžu prasit a bezohledně alokovat nové a vyšlo mi, že má asi desetinásobnou průchodnost proti MS C++. Čili za daný čas dokáže alokovat a zahodit 10x víc objektů než C++.

Tak zrovna MS C++ není úplně vypovídající. Také by mě zajímalo, jak jsi to měřil.

Ano, můžeš zkoušet různé countery, vektory, předalokace, dealokace a věřit, že tím obejdeš nevýhody new/delete. Však si to někdy zkus. Můj první příspěvek byl právě o tom, že GC je v tomhle přinejmenším dobrý kompromis vzhledem k tomu, jak to usnadňuje práci programátora. Ano, namítáš, že C++ programátor si může vybrat, já říkám, že výkon tohoto mechanismu je tak mizerný, že u složitějších problémů je k tomu donucen.

GC má samozřejmě overhead, ale když na něj dojde, tak často existuje jen zlomek objektů, co prošly tím programem. Pořeší tento zlomek a je hotovo. Delete se poctivě stará o každých pár byte co si někde alokuješ, to je prostě ohromný rozdíl.
Dělal jsem spoustu měření na různě složitých algoritmech. Pro lowlevel benchmark jsem si prostě udělal pole řádově tisíce pointerů a do toho jsem alokoval stále nové objekty. Ty něco triviálního počítaly a pak je přeplácnul nový objekt. Tohle samozřejmě GC chutná nejvíc, takže se tam projeví výhody proti delete.

[Zabanovaný Anonymní Troll]

Proc to vubec resime toto. Kazdy proste vime, ze Java je pomala a nenazrana, pomalu startuje, v provnani treba s Go, nebo Swift, nebo Objective-C.

Ne, to „víte“ jenom vy. A řešíme to proto, abyste se dozvěděl, jak je to doopravdy. Když provedení aplikace v Go trvá průměrně 260 ms a doba běhu aplikace (s tím samým algoritmem) v Javě trvá průměrně 166 ms, nevypadá to, že by Java byla v porovnání s Go pomalejší. Spíš to vypadá opačně.

1. Oracle - kolik bude GraalVM stat, jake bude srani s licencemi?
2. Kompilace - jak dlouho se to kompiluje v porovnani s Go?
3. GraalVM a Spring - nedari se mi vyrobit image - uz se s tim zase seru, hodina a pul zabita.
4. Konfigurace - neni to lusknutim prstu, s Go dam 1x download a mam vse.
5. Kdy bude GraalVM pripraven pro produkcni nasazeni v enterprise?

Tvl ta Java to je takova hydra, a ted ji akorat zase narostla dalsi hlava 

[Filip Jirsák]

1. Oracle - kolik bude GraalVM stat, jake bude srani s licencemi?
2. Kompilace - jak dlouho se to kompiluje v porovnani s Go?
3. GraalVM a Spring - nedari se mi vyrobit image - uz se s tim zase seru, hodina a pul zabita.
4. Konfigurace - neni to lusknutim prstu, s Go dam 1x download a mam vse.
5. Kdy bude GraalVM pripraven pro produkcni nasazeni v enterprise?

Tvl ta Java to je takova hydra, a ted ji akorat zase narostla dalsi hlava 

GraalVM Community Edition je pod GPL. Argumenty vás ale zjevně nezajímají, vy máte jasno, a když jsem vaše argumenty vyvrátil, vymyslel jste si jiné – co na tom, že jsou úplně nesmyslné. Nebo vás vážně trápí, kolik sekund trvá vytvoření nativního obrazu někde na build serveru? GraalVM vyšla zrovna před pár dny v oficiální produkční verzi. Pro nasazení v enterprise bude vhodná tak během roku dvou. Na rozdíl od Go, které by pro nasazení v enterprise potřebovalo ještě aspoň tak pět (pokud by se na tom opravdu pořádně makalo) nebo deset let vývoje celého ekosystému. Jenže ve skutečnosti nebude Go pro nasazení do enterprise vhodné nejspíš nikdy, protože k tomu není určené. Java tak sice původně také nebyla zaměřená, ale nemyslím si, že by Go zopakovalo cestu Javy. Největší smůla Go je ta, že se teď na něj lepí takoví ti rozumbradové, kteří jenom opakují memy zaslechnuté někde na internetu, ale ve skutečnosti o tom nic neví.

[Kit]

Typický GC má "množstevní slevu" proto, že se nestará o nedosažitelné objekty, řeší jen živé. To znamená, že čím déle vydrží neběžet, tím víc bude těch mrtvých a tím víc na tom ušetří. V důsledku toho je velmi levné dělat krátce žijící objekty, což má spoustu dalších pozitivních důsledků. Naopak new/delete se poctivě stará o každý objekt, což je dost neefektivní a v důsledku nutí programátora, aby se krátkodobým objektům vyhnul.

Jak se stará jen o živé? Ten overhead u GC nevadí? A proč by v C++ mělo být velmi drahé dělat krátce žijící objekty? Copak si nemůžu naalokovat paměť, kterou pak budu předávat, abych nemusel pořád alokovat a dealokovat?

Pokud chceš programovat objektově, tak stále alokuješ nové místo pro objekty, zejména pokud je děláš immutable. Dealokaci neřešíš a tím šetříš čas. Ušetříš tak např. 200 ms a hromadu řádek kódu. Pak paměť dojde a spustí se GC, kterému úklid bude trvat např. 20 ms. Budeš to sice vnímat jako lag, ale celkově jsi ušetřil 180 ms.

[Zabanovaný Anonymní Troll]

1. Oracle - kolik bude GraalVM stat, jake bude srani s licencemi?
2. Kompilace - jak dlouho se to kompiluje v porovnani s Go?
3. GraalVM a Spring - nedari se mi vyrobit image - uz se s tim zase seru, hodina a pul zabita.
4. Konfigurace - neni to lusknutim prstu, s Go dam 1x download a mam vse.
5. Kdy bude GraalVM pripraven pro produkcni nasazeni v enterprise?

Tvl ta Java to je takova hydra, a ted ji akorat zase narostla dalsi hlava 

GraalVM Community Edition je pod GPL. Argumenty vás ale zjevně nezajímají, vy máte jasno, a když jsem vaše argumenty vyvrátil, vymyslel jste si jiné – co na tom, že jsou úplně nesmyslné. Nebo vás vážně trápí, kolik sekund trvá vytvoření nativního obrazu někde na build serveru? GraalVM vyšla zrovna před pár dny v oficiální produkční verzi. Pro nasazení v enterprise bude vhodná tak během roku dvou. Na rozdíl od Go, které by pro nasazení v enterprise potřebovalo ještě aspoň tak pět (pokud by se na tom opravdu pořádně makalo) nebo deset let vývoje celého ekosystému. Jenže ve skutečnosti nebude Go pro nasazení do enterprise vhodné nejspíš nikdy, protože k tomu není určené. Java tak sice původně také nebyla zaměřená, ale nemyslím si, že by Go zopakovalo cestu Javy. Největší smůla Go je ta, že se teď na něj lepí takoví ti rozumbradové, kteří jenom opakují memy zaslechnuté někde na internetu, ale ve skutečnosti o tom nic neví.

Pane Jirsak, me uz asi nepresvedcite. Devil is in the details. Muzete se izolovane zamerit na co chcete, ale Java ukazala v podlednich 2 dekadach co je zac. Je to pomalá těžkotonážní hydra.

Já ještě teď rozdýchávám, jak mi referenční implementace pro JAX-RS, Jersey, přidala 1 vteřinu ke startu servletové Hello World aplikace.

Můžete mít GraalVM, můžete mít cokoliv, ale v Javě se, když se to vezme kolem a kolem, píšou vyrábí hrozné sračky, celá ta platfroma je složitá, stdlib je outdated a musí se furt všechno odněkud natahovat přes Maven, buildy dlouho trvají... a teď celá ta entropie platformy ještě narostla dalším featurou. Java jazyk sucks a lot, Kotlin se skoro nepoužívá, Scala už vůbec ne. Java platforma dojede na bídnou kvalitu a údržbu, je to ja jak stará zaprášená továrna z 90 let, teď do ni vestavěli sice nový blok, ale stejně už každý čeká na to, až se to celé zbourá.

No nic, zitra zase do prace, Java me dobre zivi, v enterprise nic lepsiho neni, ale uz se tesim na neco noveho.

Priznam se, ze vcelku zavidim C#-pistum .NET, ale plnohodnotna nahrada to jeste neni A navic mi C# prijdou jako hrozne nafintene nemehla.

[kimec]

Proc to vubec resime toto. Kazdy proste vime, ze Java je pomala a nenazrana, pomalu startuje, v provnani treba s Go, nebo Swift, nebo Objective-C.

Ne, to „víte“ jenom vy. A řešíme to proto, abyste se dozvěděl, jak je to doopravdy. Když provedení aplikace v Go trvá průměrně 260 ms a doba běhu aplikace (s tím samým algoritmem) v Javě trvá průměrně 166 ms, nevypadá to, že by Java byla v porovnání s Go pomalejší. Spíš to vypadá opačně.

1. Oracle - kolik bude GraalVM stat, jake bude srani s licencemi?
2. Kompilace - jak dlouho se to kompiluje v porovnani s Go?
3. GraalVM a Spring - nedari se mi vyrobit image - uz se s tim zase seru, hodina a pul zabita.
4. Konfigurace - neni to lusknutim prstu, s Go dam 1x download a mam vse.
5. Kdy bude GraalVM pripraven pro produkcni nasazeni v enterprise?

Tvl ta Java to je takova hydra, a ted ji akorat zase narostla dalsi hlava 

GraalVM nebude na enterprise nasadenie ready nikdy. Je to iba testbed project, ktory sluzi na to, aby sa ludia zacali hrat s buducimi technologiami a poskytli potrebny feedback.

Ak chcete vediet, kedy sa technologie, ktore sa na GraalVM prototypuju, stanu enterprise ready, tak to zavisi od kazdeho downstream projektu zvlast.

Osobne si myslim, ze taky zasadny milnik pre bezneho Frantu bude vtedy, ked vyjde stabilny release MySQL a Oracle DB s MLE. Predpokladam, ze na roote bude nejaky clanok.

Co sa tyka Javy, tak kompilacna infrastruktura z Graalu je sucastou referencnej implementacie uz od 9ny.

[Cikáda]

Jak se stará jen o živé? Ten overhead u GC nevadí? A proč by v C++ mělo být velmi drahé dělat krátce žijící objekty? Copak si nemůžu naalokovat paměť, kterou pak budu předávat, abych nemusel pořád alokovat a dealokovat?

Kdysi jsem si potřeboval ověřit, jak moc v javě můžu prasit a bezohledně alokovat nové a vyšlo mi, že má asi desetinásobnou průchodnost proti MS C++. Čili za daný čas dokáže alokovat a zahodit 10x víc objektů než C++.

Tak zrovna MS C++ není úplně vypovídající. Také by mě zajímalo, jak jsi to měřil.

Ano, můžeš zkoušet různé countery, vektory, předalokace, dealokace a věřit, že tím obejdeš nevýhody new/delete. Však si to někdy zkus. Můj první příspěvek byl právě o tom, že GC je v tomhle přinejmenším dobrý kompromis vzhledem k tomu, jak to usnadňuje práci programátora. Ano, namítáš, že C++ programátor si může vybrat, já říkám, že výkon tohoto mechanismu je tak mizerný, že u složitějších problémů je k tomu donucen.

Já si to zkoušel, ale přes unique_ptr. A nenamítám, že programátor v C++ si může vybrat, namítám, že GC není jednoznačnou výhodou a že ne-GC přístup má své nesporné výhody. Navíc nejprve by to chtělo specifikovat, co si představuješ pod pojmem "výkon".

GC má samozřejmě overhead, ale když na něj dojde, tak často existuje jen zlomek objektů, co prošly tím programem. Pořeší tento zlomek a je hotovo. Delete se poctivě stará o každých pár byte co si někde alokuješ, to je prostě ohromný rozdíl.
Dělal jsem spoustu měření na různě složitých algoritmech. Pro lowlevel benchmark jsem si prostě udělal pole řádově tisíce pointerů a do toho jsem alokoval stále nové objekty. Ty něco triviálního počítaly a pak je přeplácnul nový objekt. Tohle samozřejmě GC chutná nejvíc, takže se tam projeví výhody proti delete.

Obávám se, že tohle nechápu. Zaprvé pokud existuje zlomek objektů, co prošly programem, tak proč bych měl v ne-GC přístupu alokovat víc? Zadruhé ten GC se taky stará o každý byte, protože nechce mít memory-leaky (a ten delete volá taky) - hlavní rozdíl je "kdy" a "jak často".

Ad ten příklad - pokud sis udělal řádově tisíce pointerů a do nich alokoval stále nové objekty, které něco počítaly a pak je přeplácnul, tak nechápu, proč jsi volal delete. Delete voláš až na konci, proč bych dealokoval paměť, kterou budu vzápětí alokovat? To potom chápu, že to pro GC vyházelo lépe, ale v takovém případě je problém jinde...