Příspěvky

31

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 07. 12. 2022, 01:26:18 »

No, a já se zajímám, kde ta hranice je.

Jo takhle V pohodě, už chápu, hmm, ale je to široká otázka... Ale zkusim...

Memory leakům Rust obecně nezabrání. Zajistit invarianty jako třeba to sudé číslo nebo neprázdný string bude umět pomocí newtype, tj. asi podobně jako Haskell. Podstatné omezení aktuálního Rustu je, že nemá specializaci generik. Pracuje se na tom, existují experimentální implementace a minimální subset, který je i celkem použitelný, ale není to hotové a plně sound.

Přemýšlím, co dál, mám nějak komentovat async Rust? Pozitivum určitě je, že async podpora je celkem minimální, definuje pouze základní typy pro reprezentaci asnyc funkcí (semi-korutin) a runtimes jsou pak implementované v externích knihovnách.

Docela cool featura jsou proc-makra, tj. efektivně plugin do kompilátoru, který je použitelný jako jakákoli knihovna. Proc-makrem se dá udělat hodně... Tady je příklad, kde proc-macro během překladu parsuje a verifikuje SQL kód.

To je jen jedna metrika: optimalizovaný kód. Java nám ale kdysi ukázala, že v mnoha případech po optimalizovaném kódu na rychlost není taková poptávka jak bychom si možná přály. Zatímco po bezpečné kódu ano (Scala). A abych byl hodně cynický, tak ona možná není nijak zvláštní poptávka ani po bezpečném kódu (Clojure, C#, JS) 

Ano, přesně tak, je to jedna metrika a můj osobní pohled... Nemám v úmyslu ho vydávat za obecně závazný

32

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 07. 12. 2022, 00:47:33 »

Co znamená ta 0 mezi `auto` a jménem implicitního argumentu?

33

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 23:14:54 »

Rust je schopen zajistit, že nedojde k memory leaku.

Tady nevim přesně jak to myslíš, ale absence leaků nepatří do záruk Rust safe kódu, leaking není unsafe. OTOH  díky různým vlastnostem neleakující kód není nějak těžké psát.

Je schopen Rust vunutit, aby text byl neprázdný?

To je to samé jako utf8-korektnost, ne? Spíš rovnou vysvětli, kam tím míříš, a já zkusim líp odpovědět.

34

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 17:52:31 »

Argumentace C/C++ je varianta Godwinova zákona.

Dobře, ale principielně ten argument je IMO platný, ono by se dalo říct i třeba to, že JS v prohlížeči poskytuje větší záruky než i safe Rust, protože ti třeba neumožní omylem si smazat $HOME ... Stačí si tu metriku nadefinovat trochu jinak, než co ty asi předpokládáš...

Je schopen Rust vynutit, aby programátor zkontroloval, že tady a tady bylo pouze sudé číslo? Idris to umí.

No to zase záleží na tom, co myslíš tím "umí". Například Rust vynucuje u stringů, aby byly vždy utf8-korektní.

35

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 16:57:46 »

Run-time jazyky neposkytují vůbec žádné záruky. To je věřím jasná věc.

To se obávám, že až tak jasná věc není, typické runtime skriptovací jazyk (Python, JS, ... whatever) poskytují větší záruky než třeba C nebo C++ - nesegfaultují ti, neumožní divoce castovat typy, ...

1/ Dá se říct, že když porovnáme Rust a Haskell, tak Rust sice poskytuje značné záruky, ale také nutí uživatele aby řešil každou blbost? Zatímco Haskell a Idris jsou více abstraktní ve smyslu, že vyžadují od uživatele jen to nejnutnější?

Tohle IMO nemůžeme rozhodnout, protože to bude subjektivní. Za mě třeba pure funkce jsou víc řešení blbostí než co po mě chce Rust.

2/ Kde jsou hranice záruk, které poskytuje Rust, ale Idris je ještě je schopen poskytnout?

Tady asi nerozumim otázce...

36

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 16:30:13 »

Znamená to tedy, že ve výsledném kódu musí být tagy, typy, qqch? Že neprobíhá type erasure, tak nějak z principu? Že ve výsledném kódu musí být nějaké runtime, protože něco?

Asi nejlépe nechme type erasure apod. spát, IMO to vede spíše ke zmatení diskuse. Také s tebou souhasím, že type checking umožňuje optimalizovat a de-facto přebytečné informace z programu odstraňovat, ale IMO tady neplatí nějaký jednoduchý vztah typu čím víc proužků, tím víc adidas, tj. čím víc type-systému, tím víc optimalizace. Ironicky, uživatel Idris tohle tak trochu potvrdil tím, že odsoudil Rust type systém jako "primitivní" - pokud budeme souhlasit, pozorujeme skutečnost, kde jazyk s primitivním TS prodkuje rychlejší programy než jazyk se 'sofistikovanými' TS.

Abych ti konečně odpověděl - IMO ta otázka, jestli / jak moc sofistikované abstrakce (a které a s jakými omezeními atd.) vyžadují tlustější runtime, je otevřená. Nicméně máme určité datapointy - Haskell už existuje desítky let a má, pokud vím, celkem vymakaný kompilátor a produkovaný kód je relativně rychlý, ale - a to nemyslím jako kritiku - žádný dramatický trhač rekordů v rychlosti to není. Další datapoint je právě vývoj Rustu, kde pozoruju, jak velmi je náročné přidávat abstrakce (move semantics, korutiny, GATs, ...) při dodržení těch runtime constraints, korektnosti, ergonomie.

V sumě, můj názor je, že ten přístup, kdy se nespoutaně vyvíjí a opěvují vysoké, velmi 'sofistikované' abstrakce, s tím, že generování kódu se zoptimalizuje někdy později, není přínosný - tj. to, co dělá např. Idris/Idris2, ale nemám v úmyslu kritizovat specificky Idris, tohle se týká i spousty jiných jazyků. Vzpomínám si, že podobných diskusí o tom, jak $FPjazyk bude zanedlouho mít super optimalizující kompilátor a konkurovat C++, jsem se zúčastnil třeba 15 let zpátky... a mezitím se nic moc nezměnilo resp. zlepšení je pouze dílčí/malé. Takže ve výsledku jsem fanoušek přístupu, kdy se abstrakce vyvíjí trochu pomaleji, návrh jazyka zůstává nohama trochu více na zemi* a zároveň s tím se vyvíjí rovnou i schopnost produkovat pokudmožno optimální kód pro reálná CPU, protože to umožňuje ty zkušenosti s generováním strojového kódu reflektovat do návrhu těch abstrakcí, do návrhu IR reprezentací atd.

*) ať už si na to zvolíš víceméně jakýkoli metr, třeba lispisti nebo smalltalkisti/selfisti také rádi měří jazykům abstrakční penisy a sebe dávají na vrchol, ale metr mají jiný

37

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 14:59:49 »

Ještě pro zajímavost přidám odkaz na jazyk Carp - staticky typovaný lisp-like jazyk s memory management á la Rust (lineární typy / move semantics / borrowing, i když omezenější).

Na stránce o memory managementu mají hezkou ukázku, jak move semantics v jazyce bez GC potřebují od typového systému, jak jsem naznačoval, ještě jednu informaci - tj. vlastnost "má destruktor".

38

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 11:51:54 »

Tam bude zajímavější i ten vygenerovaný kód, protože s typem Nat se pojí zajímavé optimalizace.

Hořím zvědavostí...

39

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 11:30:18 »

Jistě, reference je normální typový konstruktor a lifetime je jen další typ pro typové parametry. Kdybych tam přidal typ “brambora”, mohl bych si ho přidat ke generické funkci, ale sofistikovanější to nebude.

No jo, jenže 'brambora' by nebyla relevantní/použitelná pro borrow checking.

To je přece princip těch tzv. implicitních parametrů (těch ve složených závorkách). Proto se může dělat type erasure (Vect nebo Matrix tam nikde není). Koukám, že už to začínáš chápat, to je fajn, diskuse nese ovoce.

Opravdu? Tobě připadá smysluplná a přínosná diskuse, kdy nejdřív prohlásíš, že typové parametry se komplet vymažou a vůbec ve výstupu nefigurují a pak čekáš, až zjistim, že ten parametr tam můžeme zpropagovat, pokud to potřebujeme, pomocí této fíčury ('implicit arguments'), a vskutu, tímto se zajišťuje ta dynamická funkčnost, o které jsme se bavili?

40

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 10:59:35 »

ale podpora ze strany runtime stále potřeba je, runtime na to místo (do té funkce getCol) tu velikost matice zpropaguje.

Ještě upřesnění: V případě, že by se ten kód kompiloval do spustitelného kódu, bylo by možné to opravdu udělat bez runtime prostě zpropagováním toho parametru jako běžného parametru funkce.

41

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 10:56:18 »

Když to shrnu, veškeré typové parametry a konstruktory (lifetimy, reference…) jsou normálně součástí typového systému Rustu (tyto mu ale nijak nepřidávají na síle),

Takže bez nich by Rust type systém podle tebe byl stejně "sofistikovaný"? (Respektive dle tebe "primitivní".)

ale borrow checking/escape analýza jsou jen algoritmy, ty nemůžou být jeho součástí už z definice (quicksort taky není součástí pole nebo seznamu, ale umí ho seřadit).

Aha, takže se hádáme spíš o pojmy než o type systémy jazyků. Mně se to jeví tak, že když z funkce zkusim vrátim hodnotu se špatným lifetime a kompilátor tohle odmítne, je to principielně stejné jako když se pokusim z té funkce vrátit špatný typ.

Nicméně ptám se na runtime zachazející s těmi typovými parametry, o kterém jsi tvrdil, že je nutný. (...)
Sorry, ale když řekneš, že typové parametry potřebuji runtime pro boxing a já nevím co, a pak píšeš něco o matematických funkcích, tam to není dobrý argument.

Takže ještě jednou po X-té - tohle jsem napsal na základě tvého výroku, že ty typové parametry jsou komplet vymazány. Pokud vymazány nejsou, tak to potřeba není, ale podpora ze strany runtime stále potřeba je, runtime na to místo (do té funkce getCol) tu velikost matice zpropaguje.

42

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 10:44:32 »

...

Díky za hezkou sumarizaci.

Dodám jen pro úplnost, že vtables jsem postuloval předevšim za předpokladu, že 1) typový parametr je zcela vymazán a 2) abych pokryl veškeré obecné možnosti HTKs a GADTs, zejména v situaci, kdy hraje roli dynamický vstup, IMO jsou nejobecnější způsob, jak to ve spustitelném kódu reprezentovat, i když samozřejmě optimalizace pro konkrétní případy mohou existovat...

43

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 10:33:34 »

Runtime tam žádný není.

Promiň, ale tohle už je opravdu hodně absurdní. Tak se podívej do zdrojáku, máš tam i dokonce soubor runtime.c, ve kterém je definovaný, jak TEN RUNTIME volá kód (funkce trampoline()). Tou funkcí trampoline() začíná provádění celého programu. Dále memoryManagement.c, mathFunctions.c atd., které implementují funkcioinalitu toho interpreteru.

Viděl jsi ten kód vůbec někdy? Začínám mít pocit, že ne...

44

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 10:24:05 »

linearita je prostě určitá sémantika předávání argumentů (hezky to má například Mercury, viz seriál zde na Rootu, v Rustu to je v podstatě move sémantika). Move sémantika není záležitost typového systému

Ještě se k tomuhle zeptám, z jakési morbidní zvědavosti V tom příkladu, který jsem uváděl, tj.:

Kód: [Vybrat]

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

Ty nepovažuješ lifetimes za součást typu té funkce? Anebo považuješ, ale nesouhlasíš, že popisují způsob, jakým ta funkce přesouvá (move) či si půjčuje (borrow) argumenty a jakou ownership/borrowing vlastnost k nim má návratová hodnota?

45

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 06. 12. 2022, 10:16:01 »

Také jsem zjistil, že Idris [...] - měl jsem dříve představu, že to je kompilovaný jazyk jako Haskell.

Je kompilovaný, ty si to pleteš a asi myslíš, že generuje přímo nativní kód.

To si samozřejmě nemyslim, předpokládám, že kompilace Haskellu zahrnuje minimálně jednu (spíš bych předpokládal více) intermediate reprezentací.

Move sémantika není záležitost typového systému

Záleží na implementaci, v C++ je move sémantika naprasená víceméně pouze ve standardní knihovně (edit: nad typovou fíčurou "r-value references"). V Rustu je s typy provázána mnohem více, potřebuje vědět hned několik vlastností daného typu - kromě linerarity a [ne]kopírovatelnosti ještě jednu, která je IMO zajímavá, ve starších implementacích kvůli tomu musela být do některých typů přidávána datová položka - pokud budeš vědět, co to je, dostaneš také malé bezvýznamné plus