Příspěvky

61

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 14:17:20 »

Tohle všechno je záležitost implementace runtimu.

Ne, není, v Idrisu, Leanu a podobných jazycích (pro které byl ten příklad) to je záležitost typové kontroly při překladu. Akorát je ta typová kontrola mnohem sofistikovanější než v C++ nebo Rustu (induktivní typy apod.).

Po tisící, Idris nic neboxuje, umí si to ověřit při překladu v rámci statické typové kontroly.

Ano, ta typová kontrola probíhá při překladu, to já nijak nerozporuju, ale ten vygenerovaný kód, který je produktem toho kompilátoru, musí pak nutně záviset na runtime vlastnostech. V tom jednoduchém příkladě s vektorem by pravděpodobně opravu šlo tu velikost úplně vymazat a používat tu hodnotu bez indirekce atd., pokud to překladač dostatečně chytře zoptimalizuje, ale jakmile bude to bude složitější, nepůjde to. Třeba u těch matic, pokud budeš chtít použít jinou reprezentaci pro matice v závislosti na velikosti (například nějakou optimalizovanou/sparse reprezentaci pro velké matice), pak nutně bude potřeba ten typ s sebou nějakým způsobem mít v runtime, protože ty operace budou fungovat trochu jinak v závislosti na reprezentaci, minimálně nějaký tag tam bude muset být a runtime ho bude muset znát, vytvořit hodnotu se správným tagem apod.

Prostě borrow checking v Rustu používá typové parametry (pro lifetimy, to tady jistě všichni víme), ale není součástí typového systému (což zní jako blábol už na první pohled, je to jen konkrétní implementace escape analýzy).

Ne, není. Escape analýza je optimalizační technika, která je pro progamátora transparentní a není součástí sémantiky jazyka. Oproti tomu borrowing je součástí sémantiky jazyka. Tak tedy ještě jeden příklad, který je přímo z praktického kódu:

Kód: [Vybrat]

fn render_args<'j, 's: 'j>(&'s self, job: &'j RenderJob) -> Vec<&'j str> { ... }

Tady specifikuju pomocí typového systému, jaké vlastnosti má ta funkce wrt. borrowing, že výsledek je borrow jednoho z argumentů a druhý argument má k němu subtyping vztah, a tudíž je borrowing korektní. Je to principielně stejné jako třeba funkce, která by dva vektory o velikosti N a M spojila do vektoru velikosti N+M - takovou vlastnost můžeš výjádřit díky typovému systému. Stejnětak v Rustu můžu tento borrowing vztah vyjádřit typovým systémem.

Borrow checking je jedna z fází typové kontroly v Rustu. Není na tom moc co vymýšlet, snažit se to ohnout na escape analýzu nedává smysl, to je jako kdybys řekl, že výše zmíněná funkce spojující vektory je "jen trochu chytřejší bounds-checking".

Wow. Opravdu jsem nečekal, že někdo půjde až do takového absurdna, aby potopil Rust type systém...

62

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 13:10:39 »

To není pravda, kontrola toho typového parametru pro délku se provádí při překladu a pak se provede type erasure, v době běhu programu tam ten typový parametr vůbec není.

Ano, to je přesně to, o čem mluvim. Aby tohle fungovalo, musí být ta hodnota boxovaná (na-alokovaná na heapu a schovaná za, efektivně, pointer) a operace na ní se provádí přes dynamic dispatch (bude tam nějaký ekvivalent v-table), jinak by nebylo možné provést type erasure. Pokud budeš mít různé chování pro různé velikosti vektoru, bude se lišit minimálně ten vtable, případně chytřejší kompilátor nebo VM provede monomorfizaci pro různé instanciace, obojí ale efektivně znamená konstrukci typů v runtime. Tohle všechno je záležitost implementace runtimu.

Tohle Rust a C++ nemůžou udělat, protože nemůžou narozdíl od Idrisu libovolnou hodnotu implicitně boxovat a operace implicitně dynamicky dispatchovat, protože ten type systém musí být výkonově transparentní.

Borrowing v Rustu je implementován typovým systémem.

Není. Borrow checker provádí trochu chytřejší escape analýzu, kterážto je naprosto ortogonální k typům

Ne, borrowck využívá k té kontrole typové informace, co přesně ti není jasné na těch příkladech, které jsem uvedl? Ty dvě hodnoty prostě mají jiný typ, liší se typový parametr. Přijde mi, že se snažíš popřít očividné.

EDIT: To je argumentace, jako kdybych řekl, že tvoje GADT nejsou součást typového systému, protože přeci kontrolu velikosti pole mají i dynamické jazyky, které to při překladu vůbec neřeší. To je absurdní argumentace.

63

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 11:54:25 »

Pleteš si pojmy. Staticky znamená v době překladu. Ten příklad s Vect se taky ověřuje v době překladu, ale ten typový parametr pro délku vektoru nemusí být v době překladu znám. Rust a C++ pro to nemají formální prostředky, ale jiné jazyky to prostě umí (a nemusí mít GC ani runtime, to s tím vůbec nesouvisí).

Ne, nepletu, ano, přesně takhle jsem to myslel.

S runtimem i GC to souvisí, protože aby tvůj příklad fungoval, musí runtime jazyka být schopen za běhu instanciovat generický typ, vytvořit hodnotu takovéhu typu, dispatchovat na ní operace a nakonec být schopen tu hodnotu zase uvolnit. Něco takového vytvořit pro C++ a Rust je úplně jiná káva než v managed jazyku, to už by bylo mnohem jednodušší to udělat v Javě (koneckonců, odtud Scala).

A ještě jednou pro ty pomalejší, borrowing ani GC nijak nesouvisí s typovým systémem.

WTF? Borrowing v Rustu je implementován typovým systémem. Nebo jak si myslíš, že to funguje? Co přesně ti není jasné na tom, že fn foo(bar: &Bar) je syntax sugar pro generickou funkci foo<'a>(bar: &'a Bar) , kde 'a je typový parametr?

EDIT: Ještě jinak. V následujícím kódu

Kód: [Vybrat]

struct Foo<'a>(&'a str);

fn main() {
    let text = String::from("hello");

    let foo1 = Foo("hello");
    let foo2 = Foo(text.as_str());
}

jsou foo1 a foo2 hodnoty různých typů. Typ foo1 je subtype typu foo2.

64

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 11:07:41 »

Počkat, staticky ověřovat dimenzi snad v C++ (a Rustu) jde, pomocí skalárních typových argumentů (v Rustu "const generics", stále dosti experimentální fíčura, ale to je principielně jedno).

Const generics vyžadují hodnotu známou v době překladu (pro méně nechápavé to mají přímo v názvu). Jazyky se silnějšími typovými systémy toto omezení nemají (silnější = méně primitivní, ovšem jde to vyjádřit i matematicky, zná-li člověk formální aparát).

Ano, proto jsem psal staticky ověřovat. Co se týče te dynamické stránky, jazyky jako Rust nebo C++ tohle mít nemůžou nejen kvůli omezeném typového systému, ale především proto, že to vyžaduje poměrně silný runtime. Rust tohle řeší pomocí DSTs, což je způsob, jak to udělat s tenkým runtime.

To je tvůj problém. Hierarchie sofistikovaných typových systémů (pořadí podle formální síly) je “no sophistication < HKT < GADT < DP”. Rust nemá ani HKT, je v té hierarchii úplně vlevo (ta hierarchie by se dala zjemnit, třeba Julia má sice silnější typový systém než Rust, ale plnohodnotné HKT taky nemá).

To je ale pouze jeden poměrně specifický způsob jak posuzovat "sofistikovanost" a nikde není psáno, že právě tohle je ten jediný správný. Z mého pohledu typový systém Haskellu (apod.) je méně sofistikovaný, protože má horší poměr abstrakce / (výkon + korektnost) - používá komplexnější abstrakce, ale nedokáže s nimi doručit lepší vlastnosti než Rust. Navrhnout abstrakce a typový systém tak, aby poskytoval korektnost a zároveň byl výkonově transparentní, je o dost těžší než udělat to s GC a runtimem (ie. výsledek je nutně nějakým způsobem sofistikovanější).

Proto jsem zmiňoval ten borrowing, což je jedna z fíčur, díky které je tohle možné. Jsem zvyklý, že typoví teoretici si Rust ještě úplně nedokázali zaškatulkovat, ale že někdo úplně popře, že by borrowing byl fíčura typového systému, to je jinej level

65

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 01:29:50 »

Muzete mi dat priklad toho rozsireni C o memory safe reseni ?

Třeba jazyk Cyclone. Velmi obskurní dialekt Céčka. Rust se tímto jazykem/dialektem docela hodně inspiroval.

Proč Rust není pouze rozšížení Céčka? Protože by to nepřinášelo žádnou moc reálnou výhodu, byla by to pouze zybtečná komplexita a zátěž navíc. Stejně bys potřeboval kompilátor na ta rozšíření. Nijak významně by to nepomohlo ani s FFI, protože největší problém při FFI je návrh bezpečné a zároveň ergonomické abstrakce v Rustu, což by v případě rozšíření jazyka platilo úplně stejně.

66

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 01:18:23 »

U GADT je to zajímavější, umožní mi mít například toto:

Kód: [Vybrat]

data Vect : (len : Nat) -> (elem : Type) -> Type where
  Nil  : Vect Z elem
  (::) : (x : elem) -> (xs : Vect len elem) -> Vect (S len) elem

Podobně se dají udělat matice s dimenzí na úrovni typů. Navíc ty dimenze nemusí být známy v době překladu, klidně se můžou načíst ze vstupu/souboru. Tohle bez GADT nejde. Porovnání s C++, Javou nebo Rustem prostě je, že v těchto jazycích dimenze staticky ověřovat nejde (například při skalárním součinu nebo násobení matic).

Počkat, staticky ověřovat dimenzi snad v C++ (a Rustu) jde, pomocí skalárních typových argumentů (v Rustu "const generics", stále dosti experimentální fíčura, ale to je principielně jedno). Čiliže pro demonstraci GADTs to asi bude chtít nějaký složitější příklad.

Přiznám se, že tyhle komentáře mě poněkud iritují - když chci porovnávat typové systémy nějakých jazyků nebo o nich prohlašovat, že jsou 'primitivní' nebo podobně, tak by to asi chtělo ty dané jazyky také trochu znát...

67

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 05. 12. 2022, 01:01:36 »

Muj pocit neni nejake ohrozeni, popravde mi je jedno ze lide pouzivaji Rust, C#, Go, Javu, PHP, Python, atd. Jen mne opravdu nebavi resit problemy, ktere mi jini lide takto prinaseji do zivota.

A co s tim máme dělat? Ano, Rust ti přinese pravděpodobně dříve či později nějakým způsobem problémy. To ale dělá každý jazyk a nedá se s tim nic moc dělat. Nezlob se, ale je tvůj problém se nějak vyrovnat s faktem, že ostatní lidi nechtějí a nebudou používat pouze C99 na věčné časy a nikdy jinak.

Abych odpověděl na tvou předchozí otázku, Rust se aktuálně používá např. ve Firefoxu (CSS 'Quantum' engine) a používá ho několik významných firem pro backendové účely - Amazon, Dropbox, IIRC taky Facebook do nějaké míry. Používá ho taky Microsoft ale TBH nevim na co.

68

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 02. 12. 2022, 14:16:18 »

ale jinak ano, téměř všechny čistě funkcionální jazyky mají buď programy typu “IO Unit” (nebo “Effect Unit”), nebo něco na způsob Mercury (nebo oba způsoby zároveň).

To je spíš prostě jenom ukazatel toho, že programy potřebují dělat I/O. Zajímavější metrika by byla jak často programy používají třeba free monády apod.

69

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 02. 12. 2022, 11:03:39 »

Není, ale je sofistikovanější, má HKT, typové třídy a pár dalších vychytávek. Asi se shodneme, že co nejvíce kontrol je lepší dělat při překladu než za běhu.

On ten pojem "sofistikovanost" nebo "síla" nebo "složitost" typového systému je velmi vágní, bez nějaké konkretizace to prakticky nic neznamená. Ty statické záruky, které poskytuje Haskell a podobné jazyky, mi nepřijdou nijak extra slavné v poměru k tomu, jak složitý a sofistikovaný je ten typový systém, ani co do korektnosti ani výkonu.

V poslední době se tyto jazyky snaží zachránit pověst převzetím lineárních typů. Vzpomínám si, že S.P. Jones na to měl nějakou přednášku pár let zpátky. Tak uvidíme, jak se jim to podaří. Zajímalo by mě, jestli v té komunitě třeba nastala nějaká sebereflexe, jestli to předchozí sáhodlouhé opěvování monád a zygohystomorfických prepromorfismů opravdu bylo tak užitečné, jak se tvrdilo...

---

Co se týče Rustu a jeho budoucnosti, na to nikdo nedokáže odpovědět, ta budounost je stále nejistá. A to říkám jako člověk, který pracuje s Rustem od roku 2014, má nějaké (byť drobné) commity ve verzi 1.0 a pracuje full time v Rustu poslední asi 4 roky. Za mě největší aktuální otázka je, co by s Rustem bylo, kdyby nějak podstatně krachl svět kryptoměn, protože Rust je aktuálně hodně využíván právě v téhle oblasti, což na jednu stranu pomáhá, ale na druhou to je i nebezpečí. Nicméně naštěstí se množí použití Rustu i mimo krypto, takže situace se do nějaké míry zlepšuje.

Uvidíme, jak to půjde...

70

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 01. 12. 2022, 22:07:42 »

Borrowing není součást typového systému, s typy vůbec nesouvisí.

Samozřejmě že to je součást typového systému.
Ownership a borrowing je součást každého typu v Rustu, typ svoje konstituenty buďto vlastní, anebo referencuje (borrowing) a v takovém případě je to typ generický s typovými parametry druhu lifetime. I např. každá funkce, která má jako parametr referenci, je generická, i když to není explicitně zapsáno.

Většinou na tohle může člověk úplně kašlat a tvářit se, že reference je prostě reference jako v C++, ale to je pouze díky inferenci a jsou situace, kdy je potřeba to zapsat explicitně včetně třeba subtypingu mezi lifetimes parametry (syntaxe 'a: 'b).

71

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 01. 12. 2022, 18:23:32 »

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?

Není to trochu odtržené od reality? IMO značná část vývojářů pracuje s typovými systémy jednoduššími než co má Rust... Navíc Rust typesystem je obecně trochu neobvyklý, i když třeba ne tak složitý jako Haskell (ownership/borrowing počítám jako součást type systemu).