P.S. BTW zajímalo by mne, zda by šlo v Rustu nějak zprovoznit toto: https://ericniebler.com/2013/07/16/f-algebras-and-c/ 
Čistě typovým systémem by to drhlo, v Rustu neuděláš ekvivalent template<template<typename> class F>
struct Fix
Jasně, to je právě HKT. Tak ale možná přes GAT?
GATs by asi implementaci usnadnily, ale stále nevidim způsob, jak naimplementovat traitu (nebo 'něco') pro jakejkoli unární typovej konstruktor...
Jo a taky lepší podpora self-referential types - to by Rustu pomohlo víc než jakékoli další FP featury...
Nejsou tohle náhodou induktivní typy?
Ne ne, to je o pointerech/referencích. Self-referential struktura v tomhle smyslu je třeba struktura A, která obsahuje referenci sama na sebe (což může být způsobeno i obsaženými typy, třeba A obsahuje B a C, B obsahuje referenci do C). Tohle interferuje s move semantics - ve chvíli, kdy ty data přemístíš, pointer přestane být platný. Aktuálně se to řeší Pinem (wrapper typ ve standardní knihovně, který zamezuje move), ale je to celkem ošklivý hack.
Jo, vim co jsou dependent types. U Rustu postup směrem k něčemu takovému nebo k HKTs moc nečekej, přeci jen, je to jazyk určený pro reálný, praktický engineering
Jasně, to je fajn, Rust je poměrně low level, má svou upřednostňovanou oblast nasazení, ale když už má třeba GAT, což je docela šílenost, tak k lepšímu typovému systému je už jen malý krůček. Například Lean se překládá do C++, proč by se nemohl překládat do Rustu?
GATs byly přidány hlavně z toho důvodu, že to je potřeba pro podporu async funkcí v traitách. (Sekundárně to pomůže např. s implementací některých iterátorů,...). Pro další/pokročilejší typové featury by musel být podobně silný důvod.
Lean neznám, ale pokud se může překládat do C++, tak by to asi do Rustu mělo jít taky...
V této souvislosti mě ještě napadá, k čemu je ve většině případů Rust, když stejně rychlý kód generuje i třeba (plně dynamický) Chez Scheme? Jasně, ten má TGC, ale to je jediný podstatný rozdíl. Ještě lepší příklad je Julia, taky používá LLVM, obchází GC (neměnitelné struktury) a efektivitou šlape na paty Rustu. Je skutečně celý ten cirkus okolo borrow checkeru potřeba? (Je to víceméně rétorická otázka, ale stejně, ve kterých případech je Rust jediná správná volba?)
No, tak zaprvé jsem k těm tvrzením skeptický. Podobná tvrzení, že high-level jazyk XY už "šlape na paty C++" (nebo v poslední době Rustu) se objevují pravidelně už desítky let. Často to je na základně specifických případů nebo benchmarků, které dobře sedí na optimalizační schopnosti daného jazyka.
Další věc je, že borrowck/lifetimes jde celkem dobře dohromady s C FFI. Céčkové API často obsahuje např. funkce, které vrací nějaký pointer na data pro nějaký handle (=nějaký opaque pointer na nějaký resource) a v dokumentaci se píše něco jako "pointer vrácený z této funkce je platný stejně dlouho jako handle" ... tyhle situace mapují v podstatě 1:1 na lifetimes v Rustu, takže pak nad tim je možné napsat abstrakci velmi tenkou, ale zároveň paměťově korkektní.
Ale samozřejmě nevtrdim, že Rust má poslední slovo a už nikdy nic lepšího nebude. Naopak, je pravděpodobný, že dřív nebo později se objeví i pro specificky použití, na které cílí Rust, něco lepšího. Možná Julia nebo Chez ... nebo něco úplně jiného... Asi uvidíme...
(Je to víceméně rétorická otázka, ale stejně, ve kterých případech je Rust jediná správná volba?)
Třeba
tady k tomu došli...
Zobrazit příspěvky
