Je Rust jazyk budoucnosti?

[BoneFlute]

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 ¹⁾ 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.

Já taky nejsem žádnej guru. Jde ale o to uvažování. (Snad nejsem moc mimo.)
Pokud v Haskellu vytvoříš strukturu (jakkoliv sofistikovanou) obrázku, provedeš na ní libovolné transformace, a ten zdrojový obrázek tam vložíš ručně jako literál, tak ti to Haskell s velkou pravděpodobností zoptimalizuje tak brutálně, že to bude třeba dvakrát rychlejší jak kdybys to napsal v assembleru. Hádej proč :-)

Když tam vytvoříš (a použiješ) parser a serializer tak se kouzlem změní pravidla hry, a Haskell bude muset optimalizovat jinak.

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.

Já se vážně obávám, že ty důvody jsou naprosto liché. Vychází z tvých bohatých zkušeností s GrallVM a JIT. Haskell nějaké laziness vůbec nezajímá, to zcela jistě problém nebude. Halt problém je věc trochu bokem. A jediné, co mě zaujalo byla skutečnost, že Haskell má nějaké defaultní nastavení zda preferovat rychlost či paměťovou náročnost. Což by bylo správně ^(tm) řešit nějakým klíčovým slovem nebo podobnou formou jazyka. Ale to opravdu neznám jestli někde v nějakém jazyce je chytře deklarativně řešeno.

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

Tohle se normálně v praxi používá. Ale je to ideově špatné :-) Takhle by se to dělat nemělo, i když to funguje.

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ší.

Jo, Haskell je vysokoúrovňový. A ve svých snech si představuju, že by to mohlo jít ještě extréměji. A někdo to chce, někdo ne. Věřím, že mi vyhrajem. :-)

[Reklama]

[Vít Šesták (v6ak)]

Pokud v Haskellu vytvoříš strukturu (jakkoliv sofistikovanou) obrázku, provedeš na ní libovolné transformace, a ten zdrojový obrázek tam vložíš ručně jako literál, tak ti to Haskell s velkou pravděpodobností zoptimalizuje tak brutálně, že to bude třeba dvakrát rychlejší jak kdybys to napsal v assembleru. Hádej proč :-)

Tak zrovna tady je to jen o tom, že něco lze spočítat již v době kompilace. V takovémto případě může kompilátor rovnou do binárky hodit výsledek...

Když tam vytvoříš (a použiješ) parser a serializer tak se kouzlem změní pravidla hry, a Haskell bude muset optimalizovat jinak.

Sorry, já to tam stále nevidím. Jsou to věci, které by si v nějaké podobě mohl kompilátor vygenerovat sám (a asi je jedno, v jakém pořadí se serializují jednotlivé složky barvy), pokud mu to pomůže. Takže moc nevidím, v čem pomůže, když to napíšu ručně.

Já se vážně obávám, že ty důvody jsou naprosto liché. Vychází z tvých bohatých zkušeností s GrallVM a JIT. Haskell nějaké laziness vůbec nezajímá, to zcela jistě problém nebude.

Haskell je lazy už v sémantice, takže to musí kompilátor zajímat...

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

Tohle se normálně v praxi používá. Ale je to ideově špatné :-) Takhle by se to dělat nemělo, i když to funguje.

Holt na konci dne je potřeba nějak splnit požadavky uživatelů, i když to někdy vyžaduje něco, čemu bychom se radši vyhnuli...

Jo, Haskell je vysokoúrovňový. A ve svých snech si představuju, že by to mohlo jít ještě extréměji. A někdo to chce, někdo ne. Věřím, že mi vyhrajem. :-)

Asi by to mohlo jít i extrémněji, a asi to bude v nějakých situacích přínosem. Obecně to ale IMHO není otázka toho, co vyhraje, ale co se hodí ve které situaci...

[BoneFlute]

Pokud v Haskellu vytvoříš strukturu (jakkoliv sofistikovanou) obrázku, provedeš na ní libovolné transformace, a ten zdrojový obrázek tam vložíš ručně jako literál, tak ti to Haskell s velkou pravděpodobností zoptimalizuje tak brutálně, že to bude třeba dvakrát rychlejší jak kdybys to napsal v assembleru. Hádej proč :-)

Tak zrovna tady je to jen o tom, že něco lze spočítat již v době kompilace. V takovémto případě může kompilátor rovnou do binárky hodit výsledek...

Tak. A o tom to je.

Když tam vytvoříš (a použiješ) parser a serializer tak se kouzlem změní pravidla hry, a Haskell bude muset optimalizovat jinak.

Sorry, já to tam stále nevidím. Jsou to věci, které by si v nějaké podobě mohl kompilátor vygenerovat sám (a asi je jedno, v jakém pořadí se serializují jednotlivé složky barvy), pokud mu to pomůže. Takže moc nevidím, v čem pomůže, když to napíšu ručně.

Nejde o to, že si ho musíš napsat ručně. To jsem se špatně vyjádřil. Jde o to, že ho musíš definovat. Tím, že použiješ serializátor (i kdyby automatický, ale prostě ho máš a použiješ), tak tím zabráníš kompilátoru v možnosti celej obrázek zahodit. Když použiješ parser, tak kompilátor najednou neví jak přesně ty hodnoty budou vypadat a nemůže to rovnou hodit do binárky. Věřím, že to je ti jasné.

Hlavně, počítá se začátek a konec. To mezi tím je nedůležité (nadsázka).

A já jsem se hlavně chytil toho tvého popisu uvažování. Když si vytvoříš strukturu trojice barev, a tu dáš do dvou rozměrného pole, tak ty tím Haskellu (nebo libovolnému jinému jazyku) neříkáš, že skutečně musí vytvořit strukturu tak jak jsi ji popsal. Vůbec ne. On si to klidně může přeložit jako proud bytů [červerná zelená modrá červená zelená modrá ...]. Nebo může udělat tři separátní proudy. Nebo ještě jinak. Nemusí tam být jedinej ukazatel. Prostě nemusí. Proč by měl?

Stejně jako když funkcionální jazyk má všechno immutable, tak to přeci taky neznamená, že v:

Kód [Vybrat] Rozbalit


let xs = [1 .. 256]
let xs1 = filter f1 xs
let xs2 = map f2 xs1

budou tři 256prvkové pole.

v čem pomůže, když to napíšu ručně.

Ty mu řekneš, že na vstupu a výstupu je pořadí barev je RGB. To on neví, to mu musíš určit. Ale mezi tím si ty barvy pomíchá třeba na BGR. Nebo po klastrech.

Já se vážně obávám, že ty důvody jsou naprosto liché. Vychází z tvých bohatých zkušeností s GrallVM a JIT. Haskell nějaké laziness vůbec nezajímá, to zcela jistě problém nebude.

Haskell je lazy už v sémantice, takže to musí kompilátor zajímat...

Proč by mělo? Kompilátor samozřejmě rozumí tomu, že je to lazy, ale to přeci neznamená, že to lazy být musí. Jen se to tak musí jakože chovat navenek. To je to samé jako s tou immutabilitou. Samozřejmě, že kompilátor brutálně přepisuje tu samou paměť.

[Vít Šesták (v6ak)]

Nejde o to, že si ho musíš napsat ručně. To jsem se špatně vyjádřil. Jde o to, že ho musíš definovat. Tím, že použiješ serializátor (i kdyby automatický, ale prostě ho máš a použiješ), tak tím zabráníš kompilátoru v možnosti celej obrázek zahodit. Když použiješ parser, tak kompilátor najednou neví jak přesně ty hodnoty budou vypadat a nemůže to rovnou hodit do binárky. Věřím, že to je ti jasné.

Aha, takže IIUC jde o klasický trik, který se používá u benchmarků, aby kompilátor ,,nepodváděl". Výslednou hodnotu pošle někam do /dev/null, ale poslat ji musí, aby nešidil. Ale potom to není jen o nadefinování parseru/serializéru, ale i o jejich použití.

A já jsem se hlavně chytil toho tvého popisu uvažování. Když si vytvoříš strukturu trojice barev, a tu dáš do dvou rozměrného pole, tak ty tím Haskellu (nebo libovolnému jinému jazyku) neříkáš, že skutečně musí vytvořit strukturu tak jak jsi ji popsal. Vůbec ne. On si to klidně může přeložit jako proud bytů [červerná zelená modrá červená zelená modrá ...]. Nebo může udělat tři separátní proudy. Nebo ještě jinak. Nemusí tam být jedinej ukazatel. Prostě nemusí. Proč by měl?

S tím libovolným jiným jazykem to je asi trochu silné tvrzení, ale v případě Haskellu to asi platí.

Stejně jako když funkcionální jazyk má všechno immutable, tak to přeci taky neznamená, že v:

Kód [Vybrat] Rozbalit


let xs = [1 .. 256]
let xs1 = filter f1 xs
let xs2 = map f2 xs1

budou tři 256prvkové pole.

To ne, zejména v Haskellu, který je líný.

Proč by mělo? Kompilátor samozřejmě rozumí tomu, že je to lazy, ale to přeci neznamená, že to lazy být musí. Jen se to tak musí jakože chovat navenek. To je to samé jako s tou immutabilitou. Samozřejmě, že kompilátor brutálně přepisuje tu samou paměť.

V případě laziness má kompilátor teoreticky celkem volné ruce, prakticky to není tak snadné. Aby to bylo korektní, musí se poprat se situacemi, kdy a. výpočet skončí chybou a b. výpočet neskončí nikdy, nebo by trval extrémně dlouho. V praxi to v kombinaci s neřešitelností problému zastavení bude znamenat, že budou existovat situace, kdy by šlo použít striktní vyhodnocení, ale kompilátor to nezjistí.

[BoneFlute]

Nejde o to, že si ho musíš napsat ručně. To jsem se špatně vyjádřil. Jde o to, že ho musíš definovat. Tím, že použiješ serializátor (i kdyby automatický, ale prostě ho máš a použiješ), tak tím zabráníš kompilátoru v možnosti celej obrázek zahodit. Když použiješ parser, tak kompilátor najednou neví jak přesně ty hodnoty budou vypadat a nemůže to rovnou hodit do binárky. Věřím, že to je ti jasné.

Aha, takže IIUC jde o klasický trik, který se používá u benchmarků, aby kompilátor ,,nepodváděl". Výslednou hodnotu pošle někam do /dev/null, ale poslat ji musí, aby nešidil. Ale potom to není jen o nadefinování parseru/serializéru, ale i o jejich použití.

Ano. Zvolil jsem špatné slovo a zmátl tě.

A já jsem se hlavně chytil toho tvého popisu uvažování. Když si vytvoříš strukturu trojice barev, a tu dáš do dvou rozměrného pole, tak ty tím Haskellu (nebo libovolnému jinému jazyku) neříkáš, že skutečně musí vytvořit strukturu tak jak jsi ji popsal. Vůbec ne. On si to klidně může přeložit jako proud bytů [červerná zelená modrá červená zelená modrá ...]. Nebo může udělat tři separátní proudy. Nebo ještě jinak. Nemusí tam být jedinej ukazatel. Prostě nemusí. Proč by měl?

S tím libovolným jiným jazykem to je asi trochu silné tvrzení, ale v případě Haskellu to asi platí.

Tak tím libovolným nemyslím doslova libovolným, ale asi by to nemělo mít nějaké zvláštní omezení.

Stejně jako když funkcionální jazyk má všechno immutable, tak to přeci taky neznamená, že v:

Kód [Vybrat] Rozbalit


let xs = [1 .. 256]
let xs1 = filter f1 xs
let xs2 = map f2 xs1

budou tři 256prvkové pole.

To ne, zejména v Haskellu, který je líný.

Kód [Vybrat] Rozbalit


let xs = strictList [1 .. 256]
let xs1 = strictList $ filter f1 xs
let xs2 = strictList $ map f2 xs1

Lepší?

Proč by mělo? Kompilátor samozřejmě rozumí tomu, že je to lazy, ale to přeci neznamená, že to lazy být musí. Jen se to tak musí jakože chovat navenek. To je to samé jako s tou immutabilitou. Samozřejmě, že kompilátor brutálně přepisuje tu samou paměť.

V případě laziness má kompilátor teoreticky celkem volné ruce, prakticky to není tak snadné. Aby to bylo korektní, musí se poprat se situacemi, kdy a. výpočet skončí chybou a b. výpočet neskončí nikdy, nebo by trval extrémně dlouho. V praxi to v kombinaci s neřešitelností problému zastavení bude znamenat, že budou existovat situace, kdy by šlo použít striktní vyhodnocení, ale kompilátor to nezjistí.

Ano, to jistě. Určitě tam budou nějaké hranice. A snaha programovacích jazyků (k danému tématu o kterém sa bavím) je vytvořit paradigma, aby se do těchto situací nedostával (což lazyness zrovna není moc zásah do černého, asi, nevím) a přitom vývojář nemusel pomáhat. Protože když se vývojář snaží pomáhat, vždy škodí.

[Reklama]

[Rike]

Dal by mi někdo tip na literaturu k Rustu nad rámec té jejich defaultní knihy, co mají na webu? Něco, co se víc zaměřuje na praktické využití, návrhové vzory a obvyklé postupy, hlubší pochopení lifetime a bude to relativně nové (aby to obsahovalo ty poslední změny, které se mi jeví totálně nečitelné)?

[JsemJenMetar]

https://nostarch.com/rust-rustaceans

[Sam]

Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Tak my lide jsme obecne dobri ve hre s nazvem "tristeni sil".  Tak tu mame 300neodladenych distribuci a nove jazyky vznikajici jak houby po desti. Psi stekaji a karavana jde dal.

[Idris]

Tak my lide jsme obecne dobri ve hre s nazvem "tristeni sil".  Tak tu mame 300neodladenych distribuci a nove jazyky vznikajici jak houby po desti. Psi stekaji a karavana jde dal.

Specializované jazyky mohou mít smysl. Rust vznikl pro napsání jádra prohlížeče, jen se to pak nějak vymklo.

[oss]

Tak my lide jsme obecne dobri ve hre s nazvem "tristeni sil".  Tak tu mame 300neodladenych distribuci a nove jazyky vznikajici jak houby po desti. Psi stekaji a karavana jde dal.

Specializované jazyky mohou mít smysl. Rust vznikl pro napsání jádra prohlížeče, jen se to pak nějak vymklo.

A vyzera to, ze nakoniec v nom to jadro prehladaca aj tak nebude.

[ondra05]

Tak my lide jsme obecne dobri ve hre s nazvem "tristeni sil".  Tak tu mame 300neodladenych distribuci a nove jazyky vznikajici jak houby po desti. Psi stekaji a karavana jde dal.

Specializované jazyky mohou mít smysl. Rust vznikl pro napsání jádra prohlížeče, jen se to pak nějak vymklo.

Ale nevznikl, byl to původně osobní projekt Graydona Hoarea až to poté Mozilla začala rozvíjet pro Servo ale od začátku to byl jazyk na obecné použití.

[Idris]

hloubkové pochopení typového systému a dalších aspektů Rustu přesahuje mentální obzor poměrně velké skupiny programátorů (nechme stranou debaty, jestli by se neměli raději živit něčím jiným).

Typový systém Rustu je primitivní, podstatně jednodušší než v případě již zmíněného OCamlu, Scaly nebo Haskellu (raději pomiňme Agdu, Coq a spol.). Nevím, jak se ten "mentální obzor" měří, ale co to je za vývojáře, kteří nepochopí ani typy Rustu?

[Ink]

hloubkové pochopení typového systému a dalších aspektů Rustu přesahuje mentální obzor poměrně velké skupiny programátorů (nechme stranou debaty, jestli by se neměli raději živit něčím jiným).

Typový systém Rustu je primitivní, podstatně jednodušší než v případě již zmíněného OCamlu, Scaly nebo Haskellu (raději pomiňme Agdu, Coq a spol.). Nevím, jak se ten "mentální obzor" měří, ale co to je za vývojáře, kteří nepochopí ani typy Rustu?

Ty jsi dobrý necromancer. Ano, pomiň Agdu, Coq, Scalu, OCaml a Rust a začneš se blížit realitě "normálního" programátora.

[Rike]

https://nostarch.com/rust-rustaceans

Díky za tip, objednáno.

[Petr Branik]

Tyhle diskuse me vzdy bavi a pritom odpoved je jasna. Fortran a LISP.