Názory k článku
AWS sponzoruje programovací jazyk Rust

Vybral jste selektivně pár pozitiv (někdy asi sporných) a žádná negativa. Můj pohled:

* Rust přináší zajímavou správu paměti. Jak to funguje v praxi je otázka, asi to bude mentálně náročnější než Java.
* Nároky na paměť záleží, ale tady může Rust vítězit.
* Přijde mi, že Rust přišel se zajímavým řešením bezpečného paralelismu. Plus pro Rust.
* Rust je více lowlevel. To může být někdy výhoda (ano, modul pro kernel bych v Javě nepsal, ani pomocí native-image), jindy nevýhoda (dá to více práce).
* Multiparadigma­tičnost – přijde mi jako buzzword použitelný u skoro všech současných jazyků (s výjimkami jako Haskell).
* Vyšší reliabilita – co to znamená?

Jistě, Rust je cool, přináší nové myšlenky a není zatížen tolik historií. Na druhou stranu není 100% náhradou žádného ze zmiňovaných jazyků. To by spíše mohl být náhradou za C/C++. Nezatíženost historií nicméně taky znamená menší množství vhodných 3rd party knihoven.

Nikdo seriózně netvrdí, že Rust nahrazuje Erlang nebo C# (ostatně je to z principu blbost). Rust byl vyvinut jako alternativa k C++, to dělá a jestliže si dneska nachází uplatnění i v jiných nikách, neznamená to, že má ambice něco jiného "nahradit".

Jinak k Vašim komentářům:

* Správa paměti v Rustu není otázka, je v praxi osvědčená. Funguje a ano, samozřejmě je méně intuitivní, než v GC jazycích i než v C/C++. Je to ostatně jedna z věcí, se kterou každý, kdo se učí Rust, zpočátku zápasí ("Fighting the borrow checker"). Rustovská komunita tento problém bere jako cenu, kterou je ochotna zaplatit za výhody, které to přináší.

* Nároky na paměti v Rustu nejsou z principu nižší, než u stejné aplikace třeba v C++ (ve srovnání s Javou i s Go není tolik alokací na haldě, což je výhoda), ale proti C/C++ je Rust mnohem míň náchylný k memory leakům.

* Rust má plus v paralelizaci, ale navíc překladač umí docela dobře autovektorizovat (často líp, než C).

* Rust je low-level protože míří na stejné aplikace, jako C/C++. Na psaní grafických rozhraní, databázových aplikací apod. jsou líp přizpůsobené jiné jazyky.

* Multiparadigma­tičnost: souhlas, je to prázdný buzzword.

* Vyšší spolehlivost Rust nabízí díky tomu, že k svatému grálu "Proof-carrying code" má podstatně blíž, než C++. V mnoha případech je to tak, že když něco rustovský překladač přijme, tak je garance, že tam není overflow, race condition, nulové nebo divoké pointery, leak, chyby jsou řádně ošetřené atd.

> Nikdo seriózně netvrdí, že Rust nahrazuje Erlang nebo C# (ostatně je to z principu blbost).

No, Mlocik97 se to pokoušel tvrdit pro Javu a C#, a já reagoval na něj. Srovnáváním Rustu spíše s C++ než s Javou můj názor podporujete…

A díky za vysvětlení té reliability. Já bych tomu říkal spíše safety, reliability je až věcí výsledného programu, safety k tomu může samozřejmě pomoci. A ano, to je za mě ten největší přínos Rustu.

No vidíš a já jsem myslel, že jsi postřehnul, že řeč nebyla o Rustu a že jsi to na něj stočil schválně. Zkusme se tak ale tvářit dál, když už je článek o Rustu.

28. 10. 2019, 09:50 editováno autorem komentáře

No vy píšete výhody Rustu, ale mám pocit, že ten na kterého reagujete jen psal, že považuje Perl 6 za lepší, než C#... Takže Rust s tím má společného co? Resp. Mlocik97 vůbec na Rust neútočil, takže ho nemusíte takhle bránit... :-)

Přiznám se, že ač v C# nedělám, napadne mě z fleku několik věcí, které má C# lepší než Java - třeba přetížení operátorů je věc, kterou Java citelně postrádá a i ten Kotlin, byť to je poměrně strohý jazyk, ji umí. Co nabízí Java - jako jazyk - navíc?

Pretazenie operatorov tam UMYSELNE nie je. Uz dnes mi staci ze tam dovliekli VAR. Chodte si s tymito hipster zalezitostami do javascriptu tam sa mozte realizovat. Napisat namiesto a + b nieco ako a.add(b) nevidim vzhladom k problemom ktore to prinasa ako nic prinosne (b.add(a) ak su to rozne datove typy). A co ma Java naviac? Miliardu kvalitnych kniznic a multiplatformovost.

To není žádná hipsteřina, říká se tomu konzistence a jenom opravdový fanatik si může přát, aby se jeden číselný typ dal sčítat pomocí + a jiné musely používat add() a vrcholem je javovská zrůdnost zvaná equals(). A to prosím se Java začala prosazovat v době, kdy to jiné jazyky měly dávno vyřešeno příčetně a konzistentně. Kdyby Java operátory neměla vůbec, dalo by se to brát jako vlastnost, takhle to je pouze výraz zoufalství.

K poslední větě: ano, Java má výhody jako platforma, ale jazyk je/byl prostě špatný a vývoj jde ztuha, protože si to tvůrci dlouho odmítali připustit. Vzpomeň si na kolekce před přidáním generik, to bylo maso.

28. 10. 2019, 11:04 editováno autorem komentáře

Ja si na Jave pamatam uplne vsetko dokonca ked to bol este Oak. A pri rozhovore samotny Gossling uviedol preco niektore veci nie su implmentovane ani uvazovane a bolo to na zvazenie. Odstranili z C++ vsetko problematicke a pridali zopar uzitocnych veci. A pretazovanie operatorov kde A + B ti da iny vysledok ako B + A a potom hladas ze preco to mi fakt nechyba. Co mas za problem s equals(), teda pocul som ze ludia maju problemy s length vs size() a podobne ale este som nepocul o nikom kto by mal problemy s equals().

Víš co, jak Tě tak čtu, nelze než Ti popřát, aby sis ten skvělý, super navržený jazyk užil.

Že Gosling tohle tvrdil nic neznamená. Snažit se prodat koncepční vadu jako "vlastnost" je základním uměním marketingu. V době, kdy Amiga měla barevnou animovanou grafiku, stereo PCM zvuk a multitasking a IBM PC mělo monochromatický textový režim, PC Speaker a MS-DOS, markeťáci od IBM neúnavně vysvětlovali, že grafika je hračička pro lamy, každý profesionál přece ví, že když někde bliká pozadí, tak to znamená, že text je kurzívou; beep zvládá PC Speaker dokonale a nic jiného nikdo přece nikdy nepotřeboval a multitasking je blbost, protože kdy jste naposledy psali tři dopisy současně?

Javascript také nemá přetěžování operátorů. Jde jen v některých případech změnit chování + pomocí valueOf.

S Javou jsem už léta neměl co dočinění, takže třeba se od té doby v něčem zlepšila, nicméně přinejmenším tehdy mě u ní lezly na nervy mj. tyto věci:

* Rigidní OOP a nemožnost mít toplevel funkce mimo třídy. V Javě se pak často vyskytují objekty typu "dělač toho a toho..." Vždycky jsem si říkal, co to je za nápad vymyslet jazyk, který má jenom podstatná jména a žádná slovesa

* chybějící lambda výrazy a jejich nahrazení anonymními třídami (zbytečný boilerplate...)

* nemožnost alokovat jednoduché struktury na zásobníku

* slabý typový systém a kvůli tomu dualita int/Integer a podobné další typy, s občasnými implicitními konverzemi (např. konverze pole o 1000 integerech na pole s 1000 ukazately na 1000 integerů různě roztroušených po haldě, to je "paráda"...)

* kde jsou unsigned typy?

* falešné generiky pouze na úrovni typové inference (s implicitní konverzí na Object) a bez monomorfizace

* interoperabilita s C je ten největší opruz

Ke cti C# budiž řečeno, že se vyhnulo těmto chybám. Má zase svoje problémy, ale celkově mi připadá inteligentnější, i když doopravdy dobrý jazyk určitě není ani jeden.

Mě přijde že se snažíte ze šroubováku udělat kladivo. Java je dobrý jazyk a má obrovské množství knihoven které řeší hromady skutečný problémů. Jsou veci na které je lepší použít jiný jazyk ale to je jedině dobře, a imho je poměrně univerzální. Lambdy jsou v javě od verze 8, a to že jazyk nemá featury které 90 % programátorů používá blbě je imho jenom dobře.

Rigidní OOP a nemožnost mít toplevel funkce mimo třídy.

V objektovem jazyce dava smysl, aby jednotlive cinnosti byly svazany s objekty. Samostatne zijici procedury jsou koncepcne mimo. Hezky to resi Scala.

Vždycky jsem si říkal, co to je za nápad vymyslet jazyk, který má jenom podstatná jména a žádná slovesa

Slovesa jsou metody.

A pokud opravdu touzis po samostatnych procedurach, muzes od roku 2004 (Java 5) pouzit import static.

chybějící lambda výrazy a jejich nahrazení anonymními třídami (zbytečný boilerplate...)

Lambda vyrazy jsou v Jave uz dele nez pet let (od roku 2014).

nemožnost alokovat jednoduché struktury na zásobníku

Pro programatora je docela fajn, ze nemusi toto resit a o miste alokace rozhodne runtime.

konverze pole o 1000 integerech na pole s 1000 ukazately na 1000 integerů různě roztroušených po haldě, to je "paráda"...)

Pole hodnot primitivniho typu se alokuje souvisle, zadne roztrouseni po halde se nedeje.

falešné generiky pouze na úrovni typové inference

To je bohuzel dan za zpetnou kompatibilitu.

interoperabilita s C je ten největší opruz

Interoperabilita s C je nezadouci, protoze to vede k tvorbe neprenositelnych aplikaci.

Pokud chces C++, pouzivej C++, ale nevycitej Jave, ze neni C++, obzvlast, kdyz tve predstavy o ni jsou zalozeny na neznalosti.

29. 10. 2019, 00:58 editováno autorem komentáře

nemožnost alokovat jednoduché struktury na zásobníku

Pro programatora je docela fajn, ze nemusi toto resit a o miste alokace rozhodne runtime.

konverze pole o 1000 integerech na pole s 1000 ukazately na 1000 integerů různě roztroušených po haldě, to je "paráda"...)

Pole hodnot primitivniho typu se alokuje souvisle, zadne roztrouseni po halde se nedeje.

Otravný je to, když chce člověk naalokovat třeba pole XY bodů, tam už se každý bod (instance třídy se dvěma membery, x a y) extra alokuje a v poli jsou jen ukazatele, paměťová efektivita i lokalita jsou v zadeli.. V opravdové nouzi se to dá trochu obejít jedním prokládaným polem nebo dvěma, jedno pro X a jedno pro Y, ale je to takový drbání levačkou za pravým uchem..

> Pro programatora je docela fajn, ze nemusi toto resit a o miste alokace rozhodne runtime.

Runtime má v tomhle dost svázané ruce. Stačí předat referenci nějaké metodě a ta struktura musí jít na haldu. V podstatě každé volání virtuální metody je neprůhledná bariéra pro optimalizátor.

Stačí předat referenci nějaké metodě a ta struktura musí jít na haldu. V podstatě každé volání virtuální metody je neprůhledná bariéra pro optimalizátor.

Jak to vis? Specifikace JVM je v tomto smeru schvalne nekonkretni. Ve skutecnosti runtime a JIT prekladac dela to, ze volani metod inlinuje a specializuje, takze tve predpoklady obecne vubec nemusi platit.

Celkove je takove uvazovani zhoubne. Vyssi programovaci jazyky byly vytvoreny, aby odstinily programatory od toho, jak je co realizovano na urovni stroje. Pokud to nekdo potrebuje resit (napr. z duvodu maximalniho vykonu), mel by pouzivat nizsi programovaci jazyk. Ale neni na miste vycitat vyssimu programovacimu jazyku, ze programatora odstinuje od toho, jak bude kod vykonavan konkretnim pocitacem, protoze proto ten jazyk vznikl.

Otravný je to, když chce člověk naalokovat třeba pole XY bodů, tam už se každý bod (instance třídy se dvěma membery, x a y) extra alokuje a v poli jsou jen ukazatele, paměťová efektivita i lokalita jsou v zadeli..

Toto je relevantni poznamka. Ale... Java byla navrzena jako objektovy jazyk. Kazdy objekt ma z principu nejakou svou identitu, ktera je z praktickych duvodu urcena mistem v pameti. V momente, kdy zacnes urcovat misto ulozeni, zacne se ti to rozpadat jako domecek z karet a vznikne ti z toho patvar typu C++, kde mas v tomto smeru jeden rovnak na ohybak vedle druheho.

Dejme tomu, ze by se pole chovaly, tak jak chces, a bylo mozne pole objektu alokovat na zasobniku, jak by se mela zachovat nasledujici metoda?


Point foo() {
Point[] a = new Point[1000];
return a[10];
}


Rozumne by bylo zavest hodnotove datove typy, ale udelat to poradne, chce velkou davku odvahy. Protoze hodnoty, aby davaly koncepcne smysl, by mely byt nemenne, jak to treba planuje projekt Valhalla. To bylo v pulce devadesatych let stoprocentne nepruchozi, protoze takovy jazyk by byl maloobjektovy(tm), a pak by se nasli posmevacci, ze v C++ lze hodnoty menit, a proto Java nestoji za nic. Vsimnete, si ze ani C#, pri kopirovani Javy neudelal hodnotove typy poradne.

Pro programatora je docela fajn, ze nemusi toto resit a o miste alokace rozhodne runtime.

Moc fajn to zrovna není. I tak jednoduchá věc, jako je ten bod XY, musí být vždycky na haldě i když je to pouhá lokální proměnná, s nákladnou alokací a GC. Z hlediska výkonu je to katastrofa. Java je dramaticky pomalejší, než C (ačkoli při JIT kompilaci bytekódu by to tak nemuselo být, aspoň ne v takové míře) a často má extrémně vysoké paměťové požadavky, a tohle je jeden z hlavních důvodů.

Pole hodnot primitivniho typu se alokuje souvisle, zadne roztrouseni po halde se nedeje.

Primitivní typy ano, ale Integer (na rozdíl od int) není primitivní typ a protože způsob, jak implementovat generické struktury v Javě je mít všechno jako Object, tak se i obyčejný int musí převádět na Integer a zase zpátky, což je extrémně nákladné. Novéjší verze Javy to "řeší" tím, že se tato konverze někdy dělá automaticky a neviditelně... což je asi ještě horší. Nemluvě o tom, že pracovat s polem ukazatelů na Integer místo souvislého bloku int spolehlivě zabije cache.

Otravný je to, když chce člověk naalokovat třeba pole XY bodů, tam už se každý bod (instance třídy se dvěma membery, x a y) extra alokuje a v poli jsou jen ukazatele, paměťová efektivita i lokalita jsou v zadeli.. V opravdové nouzi se to dá trochu obejít jedním prokládaným polem nebo dvěma, jedno pro X a jedno pro Y, ale je to takový drbání levačkou za pravým uchem..

Viz nahoře, úplně stačí jednoduché integery, mají-li být v nějaké polymorfní struktuře. Jazyk, ve kterém je nutné se drbat levačkou za pravým uchem abych mohl mít pole 2D vektorů, je prostě WTF. Java je nenahraditelná tím, kolik toho v ní bylo vyvinuto, ale z hlediska koncepce jazyka je to hrůza a děs.

I tak jednoduchá věc, jako je ten bod XY, musí být vždycky na haldě i když je to pouhá lokální proměnná

Nemusi, runtime dela escape analysis, a pokud zjisti, ze ten objekt neutece, tak jej alokuje na zasobniku. Nektere VM delaji i to, ze ten objekt rozbiji na prvocinitele, coz otevira uplne nove moznosti optimalizaci.

s nákladnou alokací

Alokace u GC je narocna zhruba jako posunuti ukazatele zasobniku.

s nákladnou alokací a GC.

Zapomina se, ze explicitni malloc/free ma take svou nezanedbatelnou rezii + fragmentuje se ti pamet, coz muze u dlouho bezicich aplikaci byt problem (mimochodem, to byl podle googlu jeden z duvodu pro samostatne procesy v Chrome). GC ma rezii, ale na druhou stranu se eliminuje fragmentace (a zlepsuje lokalita) kopirovanim zivych objektu na jedno misto. V realnem svete veci nejsou tak jednoduche, jak se zdaji.

Primitivní typy ano, ale Integer (na rozdíl od int) není primitivní typ a protože způsob, jak implementovat generické struktury v Javě je mít všechno jako Object, tak se i obyčejný int musí převádět na Integer a zase zpátky, což je extrémně nákladné. Novéjší verze Javy to "řeší" tím, že se tato konverze někdy dělá automaticky a neviditelně... což je asi ještě horší. Nemluvě o tom, že pracovat s polem ukazatelů na Integer místo souvislého bloku int spolehlivě zabije cache.

Jestli te trapi opravdu tohle, pouzivej C nebo C++. V Jave programuju uz notnou radku let a i datove intenzivnich algoritmu, toto nebyl nikdy zavazny problem. Pokud chces pole intu, za kazdou cenu, tak jej pouzij.

Z hlediska výkonu je to katastrofa. Java je dramaticky pomalejší, než C (ačkoli při JIT kompilaci bytekódu by to tak nemuselo být, aspoň ne v takové míře) a často má extrémně vysoké paměťové požadavky, a tohle je jeden z hlavních důvodů.

Stokrat opakovana lez? Bezne si implementuju stejne algoritmy v Jave i v C a ten rozdil je tam opravdu neni dramaticky, jak se snazis licit. Java bez JIT byva tak 2x pomalejsi, s JIT jsou to jen drobne desitky procent. Neco, co lze dnes ozelet... ostatni jazyky typy python, php jsou o rad jinde, a nikdo to neresi.

kolik toho v ní bylo vyvinuto, ale z hlediska koncepce jazyka je to hrůza a děs.

Mam spis pocit, ze jsi tu koncepci nikdy nepochopil a stale ten jazyk chces pouzivat jako C nebo C++ (a resit problemy C/C++), ale to nebude fungovat, protoze to neni C ani C++.