Buď vytvoříš dobrý návrh, protože máš brutální zázemí v podobě matematiky: Haskell.
Nebo (ne)vytvoříš dobrý návrh, protože (ne)máš historickou zkušenost. Pak je nefér se jim vysmívat.
Myslíš, že by bylo reálné narvat escape analýzu do JVM? Nebo by bylo třeba nějakého velkého zásahu do syntaxe? GraalVM ji, pokud mě zdroje neklamou, používá. Takže by to jít mohlo.
Nikdo nehejtí, to byla jen v kostce fakta (jak je podal Lattner, když porovnával GC v Javě, Julii a Go). Nikdo asi nemůže popřít, že Java fláká všechny dyn. alokace na haldu, čímž naprosto zahltí GC. Ten má teď ultrahypersofistikovaný, ale pořád to kulhá za jazyky, které na haldu skoro nic nedávají, protože tam se GC fláká, i když je poměrně primitivní. Kdysi se v Javě psaly i třeba HFT systémy, ale kód byl vždy specifický (bez alokací, případně tam byly speciální alokátory, takto by šlo dělat HFT i v Prologu).
IMHO je to jedno. Přepis je vždycky dobrá věc, protože v tom druhém kole máš už velice dobrou představu o tom, co ten program má dělat, a podle toho děláš návrh od začátku správně. Zatímco první verze začínala s čistým listem a na důležité věci se přišlo až když bylo pozdě. Zmiznou rovnáky na vohejbáky, lidově řečeno :-)
Rust (a Cargo) se mi líbí. Není to spasitel, má svoje problémy, ale když to porovnám s kvalitou současných C programů, je to úplně někde jinde. Schválně si vyber pár klasických unixových programů a podívej se, jak třeba dělají parsing argumentů příkazové řádky. Každý to dělá úplně jinak, často je vidět, že to byl něčí první C program. Přidání závislosti je víc práce, než si nějaký parser sesmolit na koleni. V Rustu každý použije jeden nebo druhý populární a perfektně otestovaný modul, protože to jde bez bolesti.
8. 5. 2023, 22:51 editováno autorem komentáře
> si vyber pár klasických unixových programů a podívej se, jak třeba dělají parsing argumentů příkazové řádky. Každý to dělá úplně jinak... Přidání závislosti je víc práce, než si nějaký parser sesmolit na koleni.
Není chyba, že přidání závislosti je více práce? Navíc obecně programy se snaží fungovat i nezávisle, což znamená mít vedle sebe vlastní parsování, s použitím knihovny 1 a knihovny 2. Navíc to pak tvůrce distribuce neotestuje se zvolenými verzemi aplikací a knihoven, jen hodí do repozitáře aktuální verze a uvidí, co budou lidi hlásit za bugy.
> V Rustu každý použije jeden nebo druhý populární a perfektně otestovaný modul, protože to jde bez bolesti.
Tohle je jen dočasná výhoda nových jazyků. Časem se zabordelí úplně stejně.
9. 5. 2023, 10:30 editováno autorem komentáře
>Navíc to pak tvůrce distribuce neotestuje se zvolenými verzemi aplikací a knihoven, jen hodí do repozitáře aktuální verze a uvidí, co budou lidi hlásit za bugy.
S ohledem na fakt že to Rust linkuje staticky tohle opravdu není problém.
A než se tu rozjede další flame na téma "Statické linkování je špatně",
Ono se toho dynamicky zas tolik nelinkuje ani teď a výhody dynamického linkování všeho možného jsou obecně spíš sporné.
Tady je nekdo naivista ...
Dam ti sem priklad nikoli uplne z programovani, byt jen o kousicek ... XML vs JSON...
XML ... je moc slozite, zbytecne ... tak vymyslime neco jednodussiho ... JSON ... je moc primitivni, neumi popsat strukturu, datove typy ... tak to do nej dodelame ...
A presne takto to skonci naprosto vzdy.
Ze sveta tuxe muzu zminit trebas ... a voiala ... X. Je to nemotorne, nabubrele ... prepisem to ... aby vysledkem (po mnoha letech kdy budou vsichni nadavat na to, co vsechno to neumi) bylo presne totez.
Ale on se vzdy najde nekdo, kdo pozvedne kriz a prohlasuje vsechny kolem za kacire a svoji pravdu za tu jedinou spravnou, aby ho nakonec na tom jeho krizi ukrizovali.
To si vsimam aj ja. najvtipnejsie ja na tom, ze sa vzdy pride s niecim jednoduchym, co oznacime za moderne, su o tom koferencie na ktore pozeram s uzasom, lebo tu super modernu featuru, ktoru tam pridali clovek pouzival v Jave pred 10-timi rokmi alebo sa v nej uz rovno povazuje za zastaralu. Az nakoniec ta modrena vec skonci rovnako zlozita alebo este horsia ako to co mala nahradit. A hura na novu jednoduchu technologiu.