Je Rust jazyk budoucnosti?

[Králík]

Na co by mi v run-time byly typy, když je nepoužívám - proč mít vtable, když jsem typy odrbal = type erasure.

Type-erased metoda neví, jaký typ ji přichází jako argument - proto se tomu říká type erasure. Tím pádem neví, jak konkrétně danou operaci nad tim argumentem provést. Buďto si může ten typ přečíst z nějakého tagu a udělat tu vidličku, anebo si přečte z vtable adresu konkrétní imeplementace a tu zavolá.

Přijde mi, že tě koncept vtable mate - vtable není typ.

[Reklama]

[Idris]

Načtu matici ze souboru.
Zjistím velikost matice, podle toho vyberu buď reprezentaci (nikoliv typ) A, nebo reprezentaci B.
Pokud je to A pošlu to "uličkou" A. Pokud je to B pošlu to uličkou B.

Konkretizuj to prosím. Představ si, že seš metoda `col`. Na základě čeho uděláš to rozhodnutí, kterou uličkou poslat maticová data?

Nejseš žádná metoda. Nic takové není.

Ve funkci načítání matice ze souboru je podmínka, která zjistí velikost dat. Pokud je to větší jak požadovaná podmínka (IF, SWITCH), tak provede větev, kde funkci col_optimalized předá získané data (surový pole bytů), pokud je menší, předá data funkci col_unoptimalized. Nikde žádné typy, nikde žádné tagy, nikde žádné vtable.

Já bych to asi rozhodoval až v col pomocí isLTE, podle mě to povede ke kratšímu kódu.

[Králík]

Nejseš žádná metoda. Nic takové není.

Ve funkci načítání matice ze souboru je podmínka, která zjistí velikost dat. Pokud je to větší jak požadovaná podmínka (IF, SWITCH), tak provede větev, kde funkci col_optimalized předá získané data (surový pole bytů), pokud je menší, předá data funkci col_unoptimalized. Nikde žádné typy, nikde žádné tagy, nikde žádné vtable.

To je ale specielní případ, kdy jsi funkci `col` inlinoval do volající funkce. Tím ses vyhnul mé otázce, ale tohle není obecné řešení, nemůžeš všude všechno inlinovat. Představ si, že funkce `col` je třeba v už zkompilované knihovně nebo z nějakého jiného důvodu nelze inlinovat.

[Idris]

Na co by mi v run-time byly typy, když je nepoužívám - proč mít vtable, když jsem typy odrbal = type erasure.

Type-erased metoda neví, jaký typ ji přichází jako argument - proto se tomu říká type erasure. Tím pádem neví, jak konkrétně danou operaci nad tim argumentem provést. Buďto si může ten typ přečíst z nějakého tagu a udělat tu vidličku, anebo si přečte z vtable adresu konkrétní imeplementace a tu zavolá.

Přijde mi, že tě koncept vtable mate - vtable není typ.

BoneFlute má pravdu, a pokud nebudeme používat typové třídy (což pro uvedené příklady nepotřebujeme), tak nikde žádná (analogie) vtable nebude.

[BoneFlute]

Na co by mi v run-time byly typy, když je nepoužívám - proč mít vtable, když jsem typy odrbal = type erasure.

Type-erased metoda neví, jaký typ ji přichází jako argument - proto se tomu říká type erasure. Tím pádem neví, jak konkrétně danou operaci nad tim argumentem provést. Buďto si může ten typ přečíst z nějakého tagu a udělat tu vidličku, anebo si přečte z vtable adresu konkrétní imeplementace a tu zavolá.

Přijde mi, že tě koncept vtable mate - vtable není typ.

Já vím přesně co je vtable, ať už v originále, nebo v tvém použití.

Co mě mate je type-erased metoda. Měl jsem za to, že type erased je chování, kdy za určitých okolností ztrácíme informaci o typu (respektive je nám zabráněno se k ní dostat). Wiki tvrdí toto: In programming languages, type erasure is the load-time process by which explicit type annotations are removed from a program, before it is executed at run-time.

Na co by mi v run-time byly typy, když je nepoužívám - proč mít vtable, když jsem typy odrbal = type erasure.

Type-erased metoda neví, jaký typ ji přichází jako argument - proto se tomu říká type erasure. Tím pádem neví, jak konkrétně danou operaci nad tim argumentem provést. Buďto si může ten typ přečíst z nějakého tagu a udělat tu vidličku, anebo si přečte z vtable adresu konkrétní imeplementace a tu zavolá.

Pokud je proveden type-erasure, tak nad tou hodnotou neznám její typ bez ohledu na nic. Takže žádný tag žádný vtable. Prostě to udělat nemlůžu, neznám typ. Nemůžu udělat vidličku nad informací, kterou nemám. Toto si prosím ujasněme.

[Reklama]

[BoneFlute]

Nejseš žádná metoda. Nic takové není.

Ve funkci načítání matice ze souboru je podmínka, která zjistí velikost dat. Pokud je to větší jak požadovaná podmínka (IF, SWITCH), tak provede větev, kde funkci col_optimalized předá získané data (surový pole bytů), pokud je menší, předá data funkci col_unoptimalized. Nikde žádné typy, nikde žádné tagy, nikde žádné vtable.

To je ale specielní případ, kdy jsi funkci `col` inlinoval do volající funkce. Tím ses vyhnul mé otázce, ale tohle není obecné řešení, nemůžeš všude všechno inlinovat. Představ si, že funkce `col` je třeba v už zkompilované knihovně nebo z nějakého jiného důvodu nelze inlinovat.

Za prvé můžu.
Za druhé mě žádný obecný případ nezajímá.
Za třetí, já tvrdím, že se v mnoha, ne-li ve většině případů informacím o typu hodnoty v runtime vyhneš. Ty tvrdíš, že nejenom, že to tam (v runtime) obecně musí být, ale navíc to v některých jazicích být musí (Haskel, Idris) a v některých (Rust) ne.

Mě by zajímalo proč.

[BoneFlute]

Načtu matici ze souboru.
Zjistím velikost matice, podle toho vyberu buď reprezentaci (nikoliv typ) A, nebo reprezentaci B.
Pokud je to A pošlu to "uličkou" A. Pokud je to B pošlu to uličkou B.

Konkretizuj to prosím. Představ si, že seš metoda `col`. Na základě čeho uděláš to rozhodnutí, kterou uličkou poslat maticová data?

Nejseš žádná metoda. Nic takové není.

Ve funkci načítání matice ze souboru je podmínka, která zjistí velikost dat. Pokud je to větší jak požadovaná podmínka (IF, SWITCH), tak provede větev, kde funkci col_optimalized předá získané data (surový pole bytů), pokud je menší, předá data funkci col_unoptimalized. Nikde žádné typy, nikde žádné tagy, nikde žádné vtable.

Já bych to asi rozhodoval až v col pomocí isLTE, podle mě to povede ke kratšímu kódu.

No hlavně to bude rozhodovat kompiler, že jo.

[Idris]

To je ale specielní případ, kdy jsi funkci `col` inlinoval do volající funkce.

Jestli už máš Idris 2, tak můžeš zkusit tohle:

Kód: [Vybrat]

import Data.Fin
import Data.Nat
import Data.Vect

data Matrix : Nat -> Nat -> Type -> Type where
  MkMatrix : (n : Nat) -> (m : Nat) -> Ptr a -> Matrix n m a

total getCol1 : Matrix n m a -> Fin m -> Vect n a
getCol1 mat col = ?r1

total getCol2 : Matrix n m a -> Fin m -> Vect n a
getCol2 mat col = ?r2

total getCol : {m : Nat} -> Matrix n m a -> Fin m -> Vect n a
getCol mat col = case isLTE m 1000 of
                   Yes _ => getCol1 mat col
                   _ => getCol2 mat col


[Králík]

Já vím přesně co je vtable, ať už v originále, nebo v tvém použití.

Co mě mate je type-erased metoda. Měl jsem za to, že type erased je chování, kdy za určitých okolností ztrácíme informaci o typu (respektive je nám zabráněno se k ní dostat). Wiki tvrdí toto: In programming languages, type erasure is the load-time process by which explicit type annotations are removed from a program, before it is executed at run-time.

Dobře, tak nějaký konkrétní příklad, třeba Javu, ať je to jednoduchý - dejme tomu, že definuješ generickou funkci static <T> void writeAsString(T object) {} která vezme object, zavolá toString() a výsledek někam zapíše. Při kompilaci z toho java ty typy odstraní a vytvoří něco jako (ne doslova) void writeAsString(Object object) ... kód tý metody tedy při volání neví, jakej typ má argument, takže metodu toString() musí volat přes vtable, nemůže ji volat přímo.

[Idris]

Já vím přesně co je vtable, ať už v originále, nebo v tvém použití.

Co mě mate je type-erased metoda. Měl jsem za to, že type erased je chování, kdy za určitých okolností ztrácíme informaci o typu (respektive je nám zabráněno se k ní dostat). Wiki tvrdí toto: In programming languages, type erasure is the load-time process by which explicit type annotations are removed from a program, before it is executed at run-time.

Dobře, tak nějaký konkrétní příklad, třeba Javu, ať je to jednoduchý - dejme tomu, že definuješ generickou funkci static <T> void writeAsString(T object) {} která vezme object, zavolá toString() a výsledek někam zapíše. Při kompilaci z toho java ty typy odstraní a vytvoří něco jako (ne doslova) void writeAsString(Object object) ... kód tý metody tedy při volání neví, jakej typ má argument, takže metodu toString() musí volat přes vtable, nemůže ji volat přímo.

A jak by toto vypadalo v Idrisu?

[BoneFlute]

Typ chovající se jako funkce. Tomu rozumím. Jak se to liší a v čem je to podobné proti průmyslovým generikám:

Kód: [Vybrat]

type IsEven<T> where T is Nat
?

P.S. Tady bych ještě dodal, že Nat je induktivní typ, což třeba C++ vůbec nemá, takže rozdíl pod pokličkou je. Ale pro programátora se to tváří jako stejná věc.

Buď prosím vysvětli, proč je to zajímavé, že je to induktivní typ, nebo, pokud si myslíš, že to není tak podstatné pro vysvětlení, tak se můžeme přesunout dál.

PS: Prosím, vůbec neuváděj C/C++. Java, Haskell, etc.

[BoneFlute]

Já vím přesně co je vtable, ať už v originále, nebo v tvém použití.

Co mě mate je type-erased metoda. Měl jsem za to, že type erased je chování, kdy za určitých okolností ztrácíme informaci o typu (respektive je nám zabráněno se k ní dostat). Wiki tvrdí toto: In programming languages, type erasure is the load-time process by which explicit type annotations are removed from a program, before it is executed at run-time.

Dobře, tak nějaký konkrétní příklad, třeba Javu, ať je to jednoduchý - dejme tomu, že definuješ generickou funkci static <T> void writeAsString(T object) {} která vezme object, zavolá toString() a výsledek někam zapíše. Při kompilaci z toho java ty typy odstraní a vytvoří něco jako (ne doslova) void writeAsString(Object object) ... kód tý metody tedy při volání neví, jakej typ má argument, takže metodu toString() musí volat přes vtable, nemůže ji volat přímo.

Jistě. <sup>1)


1)</sup> Ignorujeme skutečnost, že Java bude brutálně optimalizovat, a JITovat, takže ve skutečnosti ten kód bude všelijakej.

[Králík]

Ty tvrdíš, že nejenom, že to tam (v runtime) obecně musí být, ale navíc to v některých jazicích být musí (Haskel, Idris) a v některých (Rust) ne.

Mě by zajímalo proč.

To je možná nedorozumění. To co tvrdím v kostce je, že jazyky jako Rust nebo C++ nemůžou jen tak přejímat různé "sofistikované" abstrakce, protože musí dodržovat výkonovou transparenci svých abstrakcí (populárně "zero-cost abstractions"). Ano, ve spoustě případů může kompilátor v jazycích jako Haskell nebo Idris výsledný kód zoptimalizovat, takže výsledná cena není hrozná, to ale zkrátka není v jazyce jako Rust dostatečné, abstrakce v těchtoo jazycích musí být transparentnější, musí méně záviset na tom, jestli se zrovna v daném případě podařilo nebo nepodařilo kompilátoru kód zoptimalizovat, jestli bude GC dost rychlý a nebude moc brzdit atd.

[Králík]

¹⁾ Ignorujeme skutečnost, že Java bude brutálně optimalizovat, a JITovat, takže ve skutečnosti ten kód bude všelijakej.

Ano, samozřejmě, ale když píšeš tu generickou funkci, tak v Javě tohle nevíš, nevíš, jak se zrovna VM vyspí a za jakých podmínek usoudí, že dané volání pro nějaký typ inlinuje, jak dlouho bude trvat, než si všimne, že to je potřeba a kolik tě bude stát tato činnost VM. V C++ nebo Rustu tohle víš dopředu o dost lépe (byť samozřejmě taky ne dokonale), protože ta abstrakce je prostě výkonově transparentnější, je to predikovatelnější.

(Samozřejmě to řešení v Rustu/C++ má i svoje nevýhody - neříkám, že ne.)

[BoneFlute]

Ty tvrdíš, že nejenom, že to tam (v runtime) obecně musí být, ale navíc to v některých jazicích být musí (Haskel, Idris) a v některých (Rust) ne.

Mě by zajímalo proč.

To je možná nedorozumění. To co tvrdím v kostce je, že jazyky jako Rust nebo C++ nemůžou jen tak přejímat různé "sofistikované" abstrakce, protože musí dodržovat výkonovou transparenci svých abstrakcí (populárně "zero-cost abstractions"). Ano, ve spoustě případů může kompilátor v jazycích jako Haskell nebo Idris výsledný kód zoptimalizovat, takže výsledná cena není hrozná, to ale zkrátka není v jazyce jako Rust dostatečné, abstrakce v těchtoo jazycích musí být transparentnější, musí méně záviset na tom, jestli se zrovna v daném případě podařilo nebo nepodařilo kompilátoru kód zoptimalizovat, jestli bude GC dost rychlý a nebude moc brzdit atd.

Proti takovéto formulaci nic nemám.

Snad jen hnidopišskou poznámku, že v případě Haskellu je to záležitost "prostě se to tak stalo", nikoliv že by to z nějakého důvodu nešlo z principu. Dovedu si vyfantazírovat nějakou extenzi, která by přidávala pravidla, že tento a tento kód musí být takhle paměťově nebo rychlostně optimální etc. Možná by to ve výsledku znamenalo celej jazyk překopat, co já vím. Zde už jsem na tenkém ledě. V Haskellu jsem čistě uživatel.