Je Rust jazyk budoucnosti?

Re:Je Rust jazyk budoucnosti?
« Odpověď #150 kdy: 08. 11. 2022, 23:43:30 »
Okolo Haskellu existuje neco jako LARP kultura. Predstira se, ze vse je v Haskellu teoreticky mozne, ale v praxi to realizovat, ukazat jak, je pod uroven Haskellovske komunity intelektualu.


BoneFlute

  • *****
  • 1 960
    • Zobrazit profil
Re:Je Rust jazyk budoucnosti?
« Odpověď #151 kdy: 08. 11. 2022, 23:50:15 »
U některých jazyků vím, že objekt/struct/whatever jsou fieldy poskládané v paměti za sebe,
To potřebuješ vědět?
Lua to třeba nemá. Ačkoliv, dynamický jazyk bychom mohli považovat za trošku vysokoúrovňový.

Re:Je Rust jazyk budoucnosti?
« Odpověď #152 kdy: 09. 11. 2022, 00:36:34 »
Většinou to vědět nepotřebuju, ale někdy se to hodí. Třeba když řeším paměťovou náročnost. Extrémní příklad může být s rastrovým obrázkem. Nejpřirozeněji bych ho vyjádřil jako dvojrozměrné pole objektů typu třeba RGB. (Vím, RGB není jediná možnost, ale dejme tomu, že nám to bude stačit ) První problém je dvourozměrné pole – spousta jazyků místo toho nabídne pole polí, které je mocnější, ale méně efektivní. Druhý problém je v některých jazycích ten objekt typu RGB. Já bych potřeboval dejme tomu 3 byty na objekt (záleží na barevné hloubce, ale nekomplikujme to). V Javě se k tomu přidává už celkem slušný overhead – už jenom reference na ten objekt zabere víc, nemluvě o tom, že objekt potřebuje hlavičku jednak kvůli popisu třídy (VMT apod.) a jednak kvůli zamykání (každý objekt je i zámek). Z hlavy nereknu, kolik přesně obrázek zabere, ale zjevně to bude několikanásobně vícz než je účelné. A v Pythonu to bude ještě horší, každý objekt je i dictionary…

Mimochodem, podobné případy přinášejí zajímavý paradox – ve vyšším jazyce bych pravděpodobně použil víc low-level přístup (jako obrovské pole bytů), abych se vyhnul tomu overheadu. V low-level jazyce s vhodnou abstrakcí to není tolik potřeba

BoneFlute

  • *****
  • 1 960
    • Zobrazit profil
Re:Je Rust jazyk budoucnosti?
« Odpověď #153 kdy: 09. 11. 2022, 04:05:00 »
Většinou to vědět nepotřebuju, ale někdy se to hodí. Třeba když řeším paměťovou náročnost. Extrémní příklad může být s rastrovým obrázkem. Nejpřirozeněji bych ho vyjádřil jako dvojrozměrné pole objektů typu třeba RGB. (Vím, RGB není jediná možnost, ale dejme tomu, že nám to bude stačit ) První problém je dvourozměrné pole – spousta jazyků místo toho nabídne pole polí, které je mocnější, ale méně efektivní. Druhý problém je v některých jazycích ten objekt typu RGB. Já bych potřeboval dejme tomu 3 byty na objekt (záleží na barevné hloubce, ale nekomplikujme to). V Javě se k tomu přidává už celkem slušný overhead – už jenom reference na ten objekt zabere víc, nemluvě o tom, že objekt potřebuje hlavičku jednak kvůli popisu třídy (VMT apod.) a jednak kvůli zamykání (každý objekt je i zámek). Z hlavy nereknu, kolik přesně obrázek zabere, ale zjevně to bude několikanásobně vícz než je účelné. A v Pythonu to bude ještě horší, každý objekt je i dictionary…

Mimochodem, podobné případy přinášejí zajímavý paradox – ve vyšším jazyce bych pravděpodobně použil víc low-level přístup (jako obrovské pole bytů), abych se vyhnul tomu overheadu. V low-level jazyce s vhodnou abstrakcí to není tolik potřeba

Já bych teda intuitivně udělal RGB jako typ, a dvourozměrné pole (jak popisuješ), parser a serializer. A pak bych očekával, že ten Haskell si tu paměťovou náročnost odvodí a zoptimalizuje sám.

Ve skutečnosti vůbec netuším jak by to dopadlo. Třeba by zklamal, třeba ne. Jakou ale mám zkušenost z "vysokoúrovňových" jazyků, tak snažit se jim pomáhat s nějakou paměťovou (nebo jinou) náročností je a/ principielně chyba; b/ v praxi ale někdy třeba.

Smyslem vysokoúrovňových jazyků je, že to dokáží udělat místo tebe a lépe, a ty jim jen řekneš co chceš. Jakmile jim místo zadání začneš pomáhat s implementací, většinou je zmateš - ale tady se začínám pohybovat v tekutých píscích teorie a ideí.

Re:Je Rust jazyk budoucnosti?
« Odpověď #154 kdy: 09. 11. 2022, 09:01:53 »
Spoustu teorie, ale moc jsem tu nenašel praktické zkušenosti.

Mně Rust vyhovuje, protože lze s minimálním úsilím vyvíjet multiplatformní řešení. Instalace kompilačního prostředí je o stažení jedné binárky z netu (rustup) a jejím spuštění, na všech podporovaných platformách. Aktualizace na novou verzi rustu - opět jeden příkaz. Výsledné binárky jsou velice svižné, nemají problémy s latencí (bez GC), velice snadno přenositelné mezi platformami. Debug je plný užitečných kontrol, po vychytání problémů stačí přidat "--release" a mám několikanásobně menší binárku plnou optimalizací, která běží výkonově i paměťově úsporně, srovnatelně s Cečkem.

Vývoj je velice pohodlný a úplně stejný ve win i v linuxu - stáhnout Intellij Community version a dokliknout Rust plugin. Plugin se drží aktuálního vývoje jazyka, nová verze každých pár dnů. Idea/plugin vše naindexuje, prokliky metod externích crates vedou rovnou do jejich zdrojáků. Zobrazování chyb rovnou při psaní je zrovna v Rustu hodně užitečné, obzvláště pro poučeného začátečníka jako já.  Vývoj je nesrovnatelně rychlejší, než čekat, až s čím přijde kompilátor. Sice v community verzi nefungují v rustu breakpointy, ale to není tak velká překážka.

Snadno mohu zdrojáky crate naklonovat do vedlejšího adresáře a upravovat ji současně s mím projektem v jednom prostředí, pokud něco v nich potřebuji upravit, atd. Vyleze mi opět jedna binárka, a pokud autor crate akceptuje mé změny (typicky zveřejnění užitečných fieldů v public struktech) a vydá novou verzi, stačí v cargo.toml přehodit dependency změnit  jeden řádek na novou upstream verzi. V kompilaci nemusím měnit nic, vše se děje automaticky na pozadí.

Pro SBC/ARM si vyvinu/zkompiluji pohodlně v IDE na mnohojádrové pracovní stanici s několika velkými monitory, cross-zkompiluji do arm64 a stačí přes scp překopírovat binárku na RPi, která by se jinak při kompilaci pořádně zapotila a já předopoval kafem.

Narozdíl od C mám k dispozici pohodlnou paletu hotových struktur, pohodlí téměř jako v javě (hashmapy, hashsety, kanály mezi vlákny všech možných vlastností), dobře vyřešenou podporu chyb s minimální režií, pořádné enumy.

Kompilátor mě nutí psát přehlednější kód. Když srovnám první verzi a verzi po delším boji akceptovanou kompilátorem, snad vždycky je výsledek čistější, logičtější, méně zašmodrchaný, se správně vyřešeným vlastnictvím, atd. Obvykle si po vyřešení konkrétní stížnosti kompilátoru říkám - no jo, takhle to dává smysl, proč jsem to tak neudělal rovnou... Jsou i výjimky, kdy je zkompilovatelný kód více "přes ruku", ale s každou verzi rustu jich ubývá.

Programy napsané v rustu bych v C nikdy nenapsal, protože bych neuměl tak pečlivě hlídat paměť a hodně dlouho bych lovil segfaulty. V Rustu to po první úspěšné kompilaci funguje na 90%, i složitější programy s více vlákny.

Ve win jsem nikdy neprogramoval a s rustem jsem si troufl na javasound nativní DLL pro WASAPI Exclusive https://github.com/pavhofman/csjsound-wasapi . Je tam samozřejmě SPOUSTU prostoru ke zlepšování, ale bez rustu bych na windowsí DLL ani nepomyslel, v C/C++ jsem systémové věci ve windowsech nikdy nedělal, nevím ani v čem bych ten kód psal.


Re:Je Rust jazyk budoucnosti?
« Odpověď #155 kdy: 09. 11. 2022, 09:10:33 »
S ideou, že ve vyšším jazyku řeknu, co chci, a kompilátor to vymyslí co nejlépe, v zásadě souhlasím. A slyšel jsem nějaké anekdotické případy, kdy například GCC vyhrál nad ručně optimalizovaným assembly code, protože vývojáři kompilátoru byli zkušenější. Kompilátory (obzvlášť JIT) někdy dovedou zajímavé věci. Třeba OpenJDK a GraalVM dovedou z dynamické alokace udělat alokaci na stacku, pokud si odvodí, že proměnná má odpovídající životnost. Obávám se ale, že s podobným typem byste v Haskellu krutě pohořel. Rád bych viděl ten kompilátor, co něco takového dovede dobře zanalyzovat a optimalizovat. I pokud byste použil typ pro dvourozměrné pole (má Haskell něco takového?), potřeboval by kompilátor pár věcí, ke kterým jsem skeptický. Je tu pár úkolů, které by si vyžádaly hlubokou analýzu celého programu:

1. Zjistit, že je výhodnější striktní vyhodnocování. To není vůbec snadné. Co když uděláte nějakou náročnou operaci, ale nakonec z obrázku budete chtít jen malý výřez?
2. Vyřešit případné time/space tradeoffs. OK, možná striktní vyhodnocování sníží paměťovou náročnost, ale zvýší časovou náročnost. Co pak preferujeme?
3. Ujistit se, že striktní vyhodnocování je korektní, případně udělat plán B. Haskell má sémantiku líného vyhodnocování. Z hlediska chování to znamená, že mohu mít obrázek s vadným subpixelem (například v jeho výpočtu dělím nulou nebo nekonečný výpočet*), chyba se projeví, až ho budu číst a hlavně jenom pokud ho budu číst. To rozhodně není snadné analyzovat. Pokud si s tím kompilátor nemůže být jistý, potřebuje mít plán B (překopat datové struktury za běhu), což není sranda, a může to znamenat v podstatě náhlý zásek.
4. Následně se rozhodnout, že místo ukazatele na RGB bude výhodnější přímo samotná hodnota. To by teoreticky mohl kompilátor rozhodnout snadno, pokud ví o neměnnosti (v Haskellu OK), používá striktní vyhodnocování (vizte body výše) a může tam být jen jediný typ (žádná dědičnost, v Haskellu asi OK). Problém by trochu nastal v případě onoho plánu B, protože pak by musel překopat nikoli jeden pixel, ale rovnou celý obrázek.

Pokud byste nepoužil dvourozměrné pole, ale přímočaře [[RGB]], bylo by to pro kompilátor ještě složitější:

1. Ze samotného typu nevyplývá, že jde o obdélníkový obrázek. Ve skutečnosti může jít o obdélník s různě ustřiženým jedním (typicky pravým; záleží na interpretaci dat) okrajem, protože vnitřní seznamy mohou být různě dlouhé.
2. List je v Haskellu spojový seznam, se vším, co z toho plyne pro paměťovou náročnost a výkon. To není jen nějaký implementační detail. To Haskell vystavuje tím, že jednak můžete seznam rozdělit na head a tail, a jednak můžete k seznamu přidat nový head, a přitom zachovat původní seznam. Ano, teoreticky by se kompilátor mohl rozhodnout použít pole, čímž některé operace zlevní a jiné zdraží (jak z hlediska času, tak z hlediska paměti), ale opět není sranda toto analyzovat. To bych se ale opakoval.

BTW, nevím, k čemu by Haskellu byl parser a serializer. Typ RGB je v podstatě struktura tří 1B integerů, k tomu lze serializaci a deserializaci vygenerovat snadno automaticky.

*) Nabízí se tu argumentovat problémem zastavení. Jeho neřešitelnost nám nicméně neříká, že to nedovedeme vyřešit nikdy. Můžeme mít algoritmus, který bude říkat ano/ne/nevím, přičemž v tom „nevím“ budou jak případy, které se zastaví, tak případy, které se nezastaví. Každopádně pokud u aspoň jednoho výpočtu pixelu nevíme, kompilátor potřebuje onen plán B.

Re:Je Rust jazyk budoucnosti?
« Odpověď #156 kdy: 09. 11. 2022, 12:40:26 »
why-discord-is-switching-from-go-to-rust[/url]

Já myslel, že discord byl postaveý a Erlangu? Nebo to nelo ještě dřív nebo jiná sociální/messaging síť?

BoneFlute

  • *****
  • 1 960
    • Zobrazit profil
Re:Je Rust jazyk budoucnosti?
« Odpověď #157 kdy: 09. 11. 2022, 13:04:41 »
nevím, k čemu by Haskellu byl parser a serializer.
Protože ten je podstatný. Je to vstup a výstup pro ten typ. Takže cokoliv mezi tím může Haskell 1) optimalizovat. Pokud ho definuješ, rozvážeš mu ruce a pak už ho nějaký lazy vyhodnocování vůbec nezajímá.

To co popisuješ a jak argumentuješ je charakteristické pro JITované jazyky jako je Java a ve skutečnosti i C, kde kompilátor tomu kódu moc nerozumí. V Javě pak za běhu odvozuje charekter dat. V Haskellu má mnohem víc informací, a mnohem méně omezení.

sníží paměťovou náročnost, ale zvýší časovou náročnost. Co pak preferujeme?
Tady jsem trochu zaváhal. Netuším, zda to lze nějak ovlivňovat. V praxi se skutečně v tomto případě používá porušování toho principu "nenavádět", a začne se do toho Haskellu kecat pomocí strict a unsafe. Jestli na to jiné nástroje mají nějaké lepší instrumenty už žel netuším.


1/ Čímž netvrdím, že to dělá; vůbec netvrdím, že se to tak skutečně provede. Ale vzhledem k tomu, jaké brutální optimalizace dokáže GCC s hloupoučkým C, tak proč by to Haskell nedal ještě líp.

Idris

  • *****
  • 2 252
    • Zobrazit profil
    • E-mail
Re:Je Rust jazyk budoucnosti?
« Odpověď #158 kdy: 09. 11. 2022, 13:51:49 »
Kompilátory (obzvlášť JIT) někdy dovedou zajímavé věci. Třeba OpenJDK a GraalVM dovedou z dynamické alokace udělat alokaci na stacku, pokud si odvodí, že proměnná má odpovídající životnost.
Tohle se ve FP řeší na úrovni typového systému přes multiplicitu (nebo lineární typy). Má to tak prastaré Mercury nebo třeba Idris (to je skoro Haskell).

Re:Je Rust jazyk budoucnosti?
« Odpověď #159 kdy: 09. 11. 2022, 14:37:44 »
Já myslel, že discord byl postaveý a Erlangu? Nebo to nelo ještě dřív nebo jiná sociální/messaging síť?
Erlang pouziva WhatsApp.

Re:Je Rust jazyk budoucnosti?
« Odpověď #160 kdy: 09. 11. 2022, 15:20:35 »
Já myslel, že discord byl postaveý a Erlangu? Nebo to nelo ještě dřív nebo jiná sociální/messaging síť?
Erlang pouziva WhatsApp.

Poté co ho FB koupil byl přemigrovaný ja jejich platformu, to už je tak 3, 4 roky zpátky.

Re:Je Rust jazyk budoucnosti?
« Odpověď #161 kdy: 09. 11. 2022, 17:43:18 »
Velka cast algoritmu je z podstaty in-place. Logicky je nelze implementovat ciste funkcionalne.

Haskell vychazi z moderni "matematiky", ktera neresi zadny realny problem, jen vytvari teorie pro teorie.

"Modern Mathematics' and by similar soft intellectual trash in schools and universities"

https://archive.org/details/hammersley1968

Cil zidovske "vedy" obecne neni poznani nebo reseni praktickych problemu

Re:Je Rust jazyk budoucnosti?
« Odpověď #162 kdy: 09. 11. 2022, 21:08:00 »
nevím, k čemu by Haskellu byl parser a serializer.
Protože ten je podstatný. Je to vstup a výstup pro ten typ. Takže cokoliv mezi tím může Haskell 1) optimalizovat. Pokud ho definuješ, rozvážeš mu ruce a pak už ho nějaký lazy vyhodnocování vůbec nezajímá.

Možná to bude moje neznalost Haskellu, ale pořád mi to nedává smysl. Pokud by to mělo mít nějaký sémantický význam, ze kterého lze tu optimalizaci odvodit, mohl by to být jen nějaký příznak, a kompilátor si může parser a serializer vygenerovat u takto jednoduché struktury sám.

To co popisuješ a jak argumentuješ je charakteristické pro JITované jazyky jako je Java a ve skutečnosti i C, kde kompilátor tomu kódu moc nerozumí. V Javě pak za běhu odvozuje charekter dat. V Haskellu má mnohem víc informací, a mnohem méně omezení.

No věřím, že v Haskellu má kompilátor některé věci jednodušší. Ale jsem dost skeptický, že bez dalšího zvládne udělat ten rastr efektivně, z důvodů, které jsem psal.

sníží paměťovou náročnost, ale zvýší časovou náročnost. Co pak preferujeme?
Tady jsem trochu zaváhal. Netuším, zda to lze nějak ovlivňovat. V praxi se skutečně v tomto případě používá porušování toho principu "nenavádět", a začne se do toho Haskellu kecat pomocí strict a unsafe. Jestli na to jiné nástroje mají nějaké lepší instrumenty už žel netuším.

Věřím, že s nějakým strict byste té optimalizace dosáhl. Jistý si s tím nejsem, ale věřil bych tomu.

1/ Čímž netvrdím, že to dělá; vůbec netvrdím, že se to tak skutečně provede. Ale vzhledem k tomu, jaké brutální optimalizace dokáže GCC s hloupoučkým C, tak proč by to Haskell nedal ještě líp.

Tím jsme u toho, proč jsem Haskell označil za extrémně vysokoúrovňový. Něco napíšete, a doufáte, že se s tím kompilátor dobře popere. Neříkám, že je tento přístup špatně, někdy se hodí nízkoúrovňovější přístup (např. řešíme side channels u kryptografie, tam optimalizace kompilátoru mohou i škodit…), někdy vysokoúrovňovější.

Idris

  • *****
  • 2 252
    • Zobrazit profil
    • E-mail
Re:Je Rust jazyk budoucnosti?
« Odpověď #163 kdy: 09. 11. 2022, 21:13:23 »
Tím jsme u toho, proč jsem Haskell označil za extrémně vysokoúrovňový. Něco napíšete, a doufáte, že se s tím kompilátor dobře popere.
To je všude, ten překladač je v podstatě celkem jednoduchý. Čistě funkcionální kód v Rustu po přeložení vypadá stejně jako stejný kód v nějakém funkcionálním jazyce.

Re:Je Rust jazyk budoucnosti?
« Odpověď #164 kdy: 09. 11. 2022, 21:52:13 »
V nějaké míře ano (ostatně některé úpravy dělají i moderní CPU, takže se tomu nevyhnete ani assemblerem…), ale liší se míra.