Je Rust jazyk budoucnosti?

[BoneFlute]

Když už se bavíme o FP a zajímavých jazycích, tak Lean (4) je ještě značně rychlejší než Haskell, jelikož používá optimalizaci “functional but in-place” (tj. optimalizovaný kód je vzhledem k datovým strukturám destruktivní).

Jakože immutable struktury nejsou immutable, nebo to chápu špatně?

Protože argument pro immutable měl být (mimo jiné) i výkon, alespoň co jsem pochytil.

Výhoda Immutable je bezpečnost a snadnost pro optimalizaci. Takže ten výkon se právě dožene tím, že kompilátor má volnější ruce pro optimalizaci - interně to nemusí být immutable, musí to být immutable navenek.

[Reklama]

[Idris]

Když už se bavíme o FP a zajímavých jazycích, tak Lean (4) je ještě značně rychlejší než Haskell, jelikož používá optimalizaci “functional but in-place” (tj. optimalizovaný kód je vzhledem k datovým strukturám destruktivní).

Jakože immutable struktury nejsou immutable, nebo to chápu špatně?

Protože argument pro immutable měl být (mimo jiné) i výkon, alespoň co jsem pochytil.

Výhoda Immutable je bezpečnost a snadnost pro optimalizaci. Takže ten výkon se právě dožene tím, že kompilátor má volnější ruce pro optimalizaci - interně to nemusí být immutable, musí to být immutable navenek.

A proto je “mut” v Rustu zlo.

[BoneFlute]

Když už se bavíme o FP a zajímavých jazycích, tak Lean (4) je ještě značně rychlejší než Haskell, jelikož používá optimalizaci “functional but in-place” (tj. optimalizovaný kód je vzhledem k datovým strukturám destruktivní).

Jakože immutable struktury nejsou immutable, nebo to chápu špatně?

Protože argument pro immutable měl být (mimo jiné) i výkon, alespoň co jsem pochytil.

Výhoda Immutable je bezpečnost a snadnost pro optimalizaci. Takže ten výkon se právě dožene tím, že kompilátor má volnější ruce pro optimalizaci - interně to nemusí být immutable, musí to být immutable navenek.

A proto je “mut” v Rustu zlo.

Pro vývojáře kompilátoru.
Nám uživatelům to je ředkev.

"mut" považuji za zajímavý kompromis. Bez něj musím řešit aktualizaci stromu, což znamená, že to musí vymýšlet programátor - to je zlo ¹⁾. S "mut" tu aktualizaci stromu (tedy kam všude se ta mutace rozleze) musí řešit kompilátor, což je lepší než aby to dělal programátor; ale za tu cenu, že nejsou tak jasné hranice, kam až to může rozlézt, a někdy to může být dost. Proto je naprosto správné, že v Rustu, když už zvolili "mut", tak že je to explicitní, a implicitně je immutable.

^1/ Cokoliv, co musí vymýšlet programátor považuji za největší zlo vůbec.

[Martin Sivák]

A proto je “mut” v Rustu zlo.

Jenže přes čistě immutable struktury se na úrovni hardware psát nedá, protože reálně tam pořád jsou nějaké periferie, registry a nějaká mutable paměť na definovaných adresách.

Krom toho mut v Rustu neznamená jen samotnou mutabilitu, ale také exkluzivní přístup a garanci, že změna nic jiného paměťově nerozbije.

V ARM HALech třeba používáte mut pro periferie, u kterých máte právo změny konfigurace.

[Idris]

A proto je “mut” v Rustu zlo.

Jenže přes čistě immutable struktury se na úrovni hardware psát nedá, protože reálně tam pořád jsou nějaké periferie, registry a nějaká mutable paměť na definovaných adresách.

To se nevylučuje, sémantická neměnnost neznamená, že se nepřepisuje paměť nebo registry. Jen to je transparentní a vývojáře to nemusí zajímat. Garanci výlučnosti nebo neměnnosti (z pohledu vývojáře) zajištuje překladač.

[Reklama]

[Martin Sivák]

To se nevylučuje, sémantická neměnnost neznamená, že se nepřepisuje paměť nebo registry. Jen to je transparentní a vývojáře to nemusí zajímat. Garanci výlučnosti nebo neměnnosti (z pohledu vývojáře) zajištuje překladač.

Jenže na této úrovni už neexistuje sémantická neměnnost. Ty periferie jsou určené ke komunikaci s vnějším světem a tudíž se z principu musí měnit.

Co se řešit dá (a teoreticky musí..) je vlastnictví v daný moment. Například sdílení SPI nebo I2C sběrnice pro komunikaci s externími komponentami. Tam jazyk pomůže, ale nakonec je to stejně tak nízkoúrovňové a citlivé na časování, že programátor musí vědět co dělá.

Typicky třeba flash paměti umožňují přes externí signál přerušit svoji transakci a později pokračovat. A to je věc, co se bez přímého přístupu do registrů periferie dělá špatně i v C/C++ HAL implementacích. Přesvědčit borrow checker v Rustu, že to je opravdu v pořádku, je ještě mnohem komplikovanější. A to nemluvím o uspání, během kterého se nakonfigurovaným periferiím vypne hodinový signál nebo třeba ADC převodníku referenční napětí. V Rustu jedině přes komplet unsafe blok.

Čistě funkcionální a immutable paradigmata jsou teoreticky krásná, ale mnohdy zbytečně omezující. Mohou fungoval jen díky tomu, že někdo tu špinavou práci odvedl na nižší úrovni. Jenže to je právě doména Rustu, tak se mu dá těžko vytýkat, že není "čistý", funkcionální a plně immutable.

Za mě vhodně namíchaná kombinace funkcionálních a procedurálních vlastnosti umožňuje v praxi čitelnější a praktičtější zápis a čtení kódu.

[Idris]

To se nevylučuje, sémantická neměnnost neznamená, že se nepřepisuje paměť nebo registry. Jen to je transparentní a vývojáře to nemusí zajímat. Garanci výlučnosti nebo neměnnosti (z pohledu vývojáře) zajištuje překladač.

Jenže na této úrovni už neexistuje sémantická neměnnost.

Ale existuje, vždyť to tak jazyky mají. Typicky přes IO Unit (nebo lineární typy, viz seriál o Mercury zde na Rootu). Že to ale v praxi jde čistě funkcionálně neznamená, že máme do jádra tahat Haskell

[BoneFlute]

že někdo tu špinavou práci odvedl na nižší úrovni.

Toto bych zdůraznil

Jenže to je právě doména Rustu, tak se mu dá těžko vytýkat, že není "čistý", funkcionální a plně immutable.

A pak toto.

Výstižná formulace.

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

Rust a Haskell mají hlavně úplně jiná zaměření.

Haskell je vlastně extrémně vysokoúrovňový jazyk. Přijde mi, že cílem je, aby programátor řekl, co potřebuje spočítat, a kompilátor nějak vymyslel, jak to udělat. Což mimo jiné znamená, že má líné vyhodnocování. V Haskellu pak ani není rozdíl +syntaktický ani sémantický) mezi přiřazením do proměnné a definicí funkce bez parametrů. Prostě se to vyhodnotí, až bude potřeba. Dokonce je možné udělat nekonečný seznam všech přirozených čísel, zavolat na něm map (\x -> 500 / (x-20)). Nevadí, že je to nekonečné (dokud to nebudu chtít přečíst celé; třeba při reverse by se to projevilo, až bych chtěl tu hodnotu použít) a že na dvacátém prvků dělím nulou (dokud ho nepotřebuju). Nedovedu si s tím moc představit paralelní výpočty (nad rámec toho, co by mohl být schopen vymyslet sám kompilátor) – pokud chci něco spočítat paralelně, asi nepotřebuju dostat hromadu líných hodnot, které se někdy časem možná vyhodnotí. Už jsem se (v jiném jazyce) na tom napálil, protože u líné datové struktury došlo k vyhodnocení až při vypisování, a paralelnost byla fuč.

Rust spíš vznikl s cílem udělat Cčko komfortní. Primárně nízkoúrovňový jazyk, který spíše shodou okolností lze někdy použít místo vyšších jazyků V podstatě si můžete představit Rust jako C + lepší preprocesor pro makra + statický analyzátor hlídající paměťovou bezpečnost.

Filozoficky jsou oba jazyky úplně jinde. Proto bude problém srovnávat jejich výkon. Oba jazyky asi budou ve své třídě rychlé, vzájemné srovnání bude komplikované. Rust bude mít predikovatelnější rychlost, u Haskellu to bude víc „magie“, která jej v některých případech (kryptografie, různé realtime úlohy, …) diskvalifikuje, i kdyby tam vycházel rychlejší.

[Idris]

Rust spíš vznikl s cílem udělat Cčko komfortní. Primárně nízkoúrovňový jazyk, který spíše shodou okolností lze někdy použít místo vyšších jazyků

Aneb C + shoda okolností = Rust

[Idris]

Haskell je vlastně extrémně vysokoúrovňový jazyk.

Nevím, co tady znamená to “extrémně”, ale ano, je vysoce abstraktní. A někdy nepraktický, OCaml by byl často lepší volbou.

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

Vysokoúrovňovost beru podle totiž jak moc mám jako programátor ponětí o tom, co se děje na procesoru. U většiny vysokoúrovňových jazyků aspoň vím, co se vykoná a zhruba v jakém pořadí*. U Haskellu bych se musel hodně snažit, a stejně si tím nebudu moc jistý.

*) Ano, technicky vzato to někdy nebudu vědět ani u assembleru (spousta CPU může přehodit instrukce), ani u C (kompilátor může přehodit instrukce). Ale mám rozhodně lepší představu než u Haskellu, navíc tu máme možnosti (volatile, synchronized, …) to vynutit.

[Idris]

U většiny vysokoúrovňových jazyků aspoň vím, co se vykoná a zhruba v jakém pořadí.

To je iluze, co a v jakém pořadí se provede je jasné i v každém “do” bloku Haskellu, které jsou sekvenční z definice.

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

No v do bloku ano, ale IIUC jen. A nejvyšší úrovni. Rozhodně ne tak, jako u běžných jazyků.

Mimochodemz tato nejistota u mě proniká i do datových struktur. U některých jazyků vím, že objekt/struct/whatever jsou fieldy poskládané v paměti za sebe, u některých jazyků s nějakou hlavičkou, některé jazyky to řeší nějakou mapou (dictem). Moc nevím, jak toto vypadá v Haskellu.

[Idris]

Mimochodemz tato nejistota u mě proniká i do datových struktur. U některých jazyků vím, že objekt/struct/whatever jsou fieldy poskládané v paměti za sebe, u některých jazyků s nějakou hlavičkou, některé jazyky to řeší nějakou mapou (dictem). Moc nevím, jak toto vypadá v Haskellu.

To ani moc říct nejde, to si poskládá překladač podle multiplicity apod.