Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Matěj Strnad 05. 11. 2020, 20:46:31

Název: Je Rust jazyk budoucnosti?
Přispěvatel: Matěj Strnad 05. 11. 2020, 20:46:31
Je podle Vás Rust jazyk budoucnosti? Případně, jaké jsou pro a proti a jaké budou klíčové milníky pro Rust? Použití Rustu narozdíl od Go tolik neroste, jaký to má podle Vás důvod a může se to v horizontu 1-2 let změnit?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: okalousek 06. 11. 2020, 00:19:41
V systémovém programování? Určitě
Mikrořadiče? Samozřejmě

WebAssebly určitě poroste, takže také.
Web Backend? Pokud nepotřebujete nutně nejvyšší rychlost, tak asi ne.

JVM jazyky určitě nenahradí, ale má velkou šanci jít proti C++

Doplnění:
samozřejmě že může doplňovat backend

Pro a proti?
+ Rychlý
+ Bezpečný
+ Velká inspirace v FP (první kompilátor byl napsán v OCamlu)
+ Traity a rozumné OOP

- Šílený typový systém u řetězců (&str a String, když člověk dá split na String tak mu vznike Vektor &str...)
- Jednoduché věci se v tom dělají někdy zbytečně složitě
- Paměťová bezpečnost (ono je to dobře, jen minimálně v začátcích je velice pravděpodobné že budete zápolit s borrow-checkerem)
- Trvá než se ho naučíte

Milníky:
Neřekl bych že to postupuje v milnících. Tak to většinou nejde, ono vše jde postupně, jinak bych řekl webassembly.

Neroste oproti Go, protože Go je užitečné na mikroslužby a je jednoduché pro nováčky, takže je v trendu.

tl;Dr
Ano, je

Mimochodem: Zvídavá otázka: Jaké jazyky umíte?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 06. 11. 2020, 07:45:59
Ten split() je rozhodnutí tvúrcú API, ne?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 06. 11. 2020, 08:02:32
Je podle Vás Rust jazyk budoucnosti? Případně, jaké jsou pro a proti a jaké budou klíčové milníky pro Rust? Použití Rustu narozdíl od Go tolik neroste, jaký to má podle Vás důvod a může se to v horizontu 1-2 let změnit?

Rust je ambiciózní pečlivě navržený jazyk, Go je jazyk více pragmatický, masový. Oba mají v současnosti svoje místo, Rust roste pomaleji právě proto, že nedělá kompromisy. Pokud se komunitě podaří vyřešit některé slabší stránky, může růst i na úkor Go. Úplná masovka to ale nebude asi nikdy, protože hloubkové pochopení typového systému a dalších aspektů Rustu přesahuje mentální obzor poměrně velké skupiny programátorů (nechme stranou debaty, jestli by se neměli raději živit něčím jiným).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: oss 06. 11. 2020, 08:21:03
Za mna:
+ richli
+ typovy system, generika, enumy
+ pametovo bezpecny
+ vie sa kompilovat do DLL-ky
+ po prekonani vstupnej barriery logicky jazyk
+ pouzitelne webassembly (dolezite je to slovo pouzitelne)

- jeden subor je jeden modul (maju to aj ine jazyky, ale je to taka strasna blbost)
- premature optimalization na UTF-8 stringy, to sposobiilo, ze sa zo stringami pracuje naozaj zle, a kcoli tomu ma Rsut sam o sebe prilis vela typov stringov (str, String,  CStr,...)
- async/await len v preview
- Mozzila ma problemy, preto sa bojim o jeho buducnost


Za mna co sa tyka ucenia, Rust som zvladol za dva tyzdne, ideomaticky rust za dalsi tyzden a pol. Ano vstupna bariera je velka a clovek spocitaku naraza, ale ked pochopi principy borrowingu a vlastnenia hodnot, tak uz aj ostatne veci v jazyku zacnu davat logiku a pracuje sa v nom  lahko a richlo.

Po tom co som sa ho naucil som lutoval, ze som kedysi stracal cas s Go.Rust ma vsteky veci, ktore cloveka napadnu vyrienie miliardukrat lepsie ako Go, je to asi ked sa porovnava krasokorculovanie (Rust) s neandertalcom (Go).

Osobne si nemyslim, ze Rust sa presadi pri mirkopoictaoch, na to v nich treba az prilis vela unsafe kodu, a hlavne problemi, ktore Rust riesi v nich niesu (ked robi clovek s mikropocitami, tak si vsteku pamet  staticky alokuje dopredu).
Kde vidim buducnost su jednodoskove pocitace ale RPi, kde Rust dava perfektny zmysel.

Rust hadam nahradi veci, na ktore sa teraz pouziva Go, hlavne pre pametovo vytazene scenare.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: okalousek 06. 11. 2020, 08:36:15
Ten split() je rozhodnutí tvúrcú API, ne?
Ano, ale u jazyka se neohodnotí jen jazyk, ale hlavně také standardní knihovna, ekosystém okolo a spousta věcí
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: registrovany_ava 06. 11. 2020, 09:13:28
Ten split() je rozhodnutí tvúrcú API, ne?
Ano, ale u jazyka se neohodnotí jen jazyk, ale hlavně také standardní knihovna, ekosystém okolo a spousta věcí

1. Nevzniká Vec<&str>, ale impl Iterator<Item=&str>
2. Podle mě je to API naprosto v pořádku, co se ti nelíbí? Když splitnu String, dostanu iterátor přes pohledy do toho splitnutého stringu (tedy iterátor přes typ &str), jak lépe by to mělo být?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: registrovany_ava 06. 11. 2020, 09:17:33
- jeden subor je jeden modul (maju to aj ine jazyky, ale je to taka strasna blbost)
- premature optimalization na UTF-8 stringy, to sposobiilo, ze sa zo stringami pracuje naozaj zle, a kcoli tomu ma Rsut sam o sebe prilis vela typov stringov (str, String,  CStr,...)
- async/await len v preview

S těmi moduly je to pravda jen částečně, systém modulů v Rustu umožňuje snadno přes exporty zveřejnit jinou strukturu, než jaká je v souborech. Jeden modul jeden soubor je sane default. Mě se s tím pracuje dobře.

Ta "premature optimization" je zase sane default, ze kterého se dá utéct pomocí jiných stringových typů. Většinou ale pracuješ s UTF-8, a ta obtížná práce s ním je spíš principiální - UTF-8 je prostě složité na manipulaci, než špatný návrh jazyka/knihovny.

- async/await len v preview - není pravda.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: LadislavBohm 06. 11. 2020, 09:32:34
Pridavam jeden zajimavy clanek z praxe pri pouziti obou jazyku na masove vyuzivane sluzbe:
https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f (https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 06. 11. 2020, 10:58:01
Ten split() je rozhodnutí tvúrcú API, ne?
Ano, ale u jazyka se neohodnotí jen jazyk, ale hlavně také standardní knihovna, ekosystém okolo a spousta věcí

1. Nevzniká Vec<&str>, ale impl Iterator<Item=&str>
2. Podle mě je to API naprosto v pořádku, co se ti nelíbí? Když splitnu String, dostanu iterátor přes pohledy do toho splitnutého stringu (tedy iterátor přes typ &str), jak lépe by to mělo být?

Souhlas, je to nejtypičtější situace - obyčejně ten řez stačí a pokud ne, udělá se na něm String::from() nebo něco. Dokonce to hlídá, aby člověk po tom splitu nezkoušel ten String modifikovat (pokud se tedy ten collectnutý Vec<&str> použije, jinak se zdá, že Rust pokrčí rameny).

Že má Rust moc řetězcových a znakových typů? Jo, ale to prostě reflektuje realitu. Viz třeba OsString, který se prostě normálním Utf stringem nahradit nedá.

Jo a ještě něco - stejné API pro split() má i str. Na jednu stranu vypadá logicky, že by jeden chtěl ze Stringu mít iterátor se Stringy, ale je otázka, zda to tak opravdu je. Tu metodu šlo úplně vynechat, je to spíš zkratka, aby člověk ušetřil as_str() - tak bych to bral.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Jose D 06. 11. 2020, 12:29:28
Rust

Na linked-inu jsem tohle téma viděl od pavlixe.
Ale nejsem schopný to skrze tamní UI dohledat.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: qelurg 06. 11. 2020, 18:38:35
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ondra Satai Nekola 06. 11. 2020, 19:16:42
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 06. 11. 2020, 19:30:37
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Touché!
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: registrovany_ava 06. 11. 2020, 20:18:07
Nedávno jsem četl docela zajímavý článek: https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: alex6bbc 06. 11. 2020, 20:23:32
c++ pouzivam a je tam toho tolik, ze se me kolegove od jinych jazyku ptaji, proc se tomu vubec venuji.
takze me to stale laka k jednoduchosti c, v dnesni dobe teda spise golang.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: tomas88 06. 11. 2020, 22:42:59
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Doporučuju trochu zagooglit. Prečíst si něco o historii obou jazyků a podobně. Na obě otázky je jasná odpověď  :)

Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ondra Satai Nekola 07. 11. 2020, 06:46:59
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Doporučuju trochu zagooglit. Prečíst si něco o historii obou jazyků a podobně. Na obě otázky je jasná odpověď  :)

Tak to je další level, doporučit Google, když někdo položí řečnickou otázku. :facepalm:
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 07. 11. 2020, 07:37:53
Tak to je další level, doporučit Google, když někdo položí řečnickou otázku. :facepalm:

Lidské poznání přece stojí a padá na těch, kterým je všechno jasné. No a teď ještě mají ten Google. Představ si, že by ho měli ve starém Řecku, kdy bychom teď mohli být.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: qelurg 07. 11. 2020, 19:14:21
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Java otevřela nový segment. Python nahradil Perl.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ondra Satai Nekola 07. 11. 2020, 19:33:53
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Java otevřela nový segment. Python nahradil Perl.

Dobré přepisování historie.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: tomas88 07. 11. 2020, 19:35:27
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Doporučuju trochu zagooglit. Prečíst si něco o historii obou jazyků a podobně. Na obě otázky je jasná odpověď  :)

Tak to je další level, doporučit Google, když někdo položí řečnickou otázku. :facepalm:

Haha, to jako fakt chceš uhrát recnickou otazku? Vis vubec co to je recnicka otazka a jak se pouziva? Mozna bych te mel zase odkazat na samostudium. Tvuj predchozi prispevek ma jen dva rozumne pohledy - budto ptas se po informacich nebo trolling.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: listoper 07. 11. 2020, 19:38:16
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Java nahradila COBOL
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: redustin 07. 11. 2020, 20:14:54
Nedávno jsem četl docela zajímavý článek: https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
Děkuji za skvělý link.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ondra Satai Nekola 07. 11. 2020, 20:22:19
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Doporučuju trochu zagooglit. Prečíst si něco o historii obou jazyků a podobně. Na obě otázky je jasná odpověď  :)

Tak to je další level, doporučit Google, když někdo položí řečnickou otázku. :facepalm:

Haha, to jako fakt chceš uhrát recnickou otazku? Vis vubec co to je recnicka otazka a jak se pouziva? Mozna bych te mel zase odkazat na samostudium. Tvuj predchozi prispevek ma jen dva rozumne pohledy - budto ptas se po informacich nebo trolling.

Pardon, čekal jsem poučenější publikum.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 11. 2020, 21:44:36
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Java nahradila COBOL
doslova
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: qelurg 07. 11. 2020, 21:52:43
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Java otevřela nový segment. Python nahradil Perl.

Dobré přepisování historie.

V čem?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: jano6 07. 11. 2020, 23:25:05
Citace
Java otevřela nový segment. Python nahradil Perl.

Ja by som bol opatrný pri slove nahradil. V súčasnosti je dnes viac Perl programátorov,
ako v minulosti. Akurát ostantné jazyky sú populárnejšie a Perl nie je na očiach.
Skôr by som tipoval, že Python obsadil oblasti, ktoré mohol mať Perl. Na webe Perl
zas vytlačilo PHP.

Je pozoruhodné, že Python oveľa viac populárny ako Perl. Perl je len o 2-3 roky starší
ale jeho CPAN bol spustený v roku 1995!!! Python mal dlhé roky v tom chaos a jednodný
repozitár sa podarilo dosiahnuť len pár rokov dozadu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: redustin 09. 11. 2020, 08:26:59
Zřejmě ani kvalitní CPAN nepřebil nečitelnost perlu v porovnání s pythonem. Třeba perlí hrátky s poli, asociativními poli a skaláry...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: qelurg 09. 11. 2020, 17:04:48
Citace
Java otevřela nový segment. Python nahradil Perl.

Ja by som bol opatrný pri slove nahradil. V súčasnosti je dnes viac Perl programátorov,
ako v minulosti. Akurát ostantné jazyky sú populárnejšie a Perl nie je na očiach.
Skôr by som tipoval, že Python obsadil oblasti, ktoré mohol mať Perl. Na webe Perl
zas vytlačilo PHP.

Je pozoruhodné, že Python oveľa viac populárny ako Perl. Perl je len o 2-3 roky starší
ale jeho CPAN bol spustený v roku 1995!!! Python mal dlhé roky v tom chaos a jednodný
repozitár sa podarilo dosiahnuť len pár rokov dozadu.

No právě,  když jsem začínal s Pythonem 1.x, tak už jsem uměl Perl, a byl podstatně populárnější, byly k němu knihy a další zdroje informací. Python 2.x ho ale převálcoval.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 10. 11. 2020, 07:32:11
Citace
Java otevřela nový segment. Python nahradil Perl.

Ja by som bol opatrný pri slove nahradil. V súčasnosti je dnes viac Perl programátorov,
ako v minulosti. Akurát ostantné jazyky sú populárnejšie a Perl nie je na očiach.
Skôr by som tipoval, že Python obsadil oblasti, ktoré mohol mať Perl. Na webe Perl
zas vytlačilo PHP.

Je pozoruhodné, že Python oveľa viac populárny ako Perl. Perl je len o 2-3 roky starší
ale jeho CPAN bol spustený v roku 1995!!! Python mal dlhé roky v tom chaos a jednodný
repozitár sa podarilo dosiahnuť len pár rokov dozadu.

1. PyPI je na světě od roku 2002, ale Python měl poměrně obsáhlou knihovnu v základní instalaci (batteries included). CPAN přinášel slušný dependency hell, vzpomínám si, jak jedno české fórum běželo na redakčním systému, který stavěl nad konkrétními verzemi knihoven z CPANu a jak bolestné bylo ho rozjet. Python už tenkrát měl Django a další podobné počiny, které fungovaly jinak. PyPi je výhoda, ale že bychom perlistům tenkrát nějak zvlášť záviděli, to ani ne.

2. Python se prosadil v oblastech, kam Perl nikdy neproniknul nebo se používal okrajově, ať už to je skriptování her nebo různých aplikací nebo vědecké výpočty.

3. V oblasti "systémových skriptů" vytlačuje řešení psaná dříve nejenom v Perlu, ale i v shellu nebo třeba C. Co je ale podstatné a v tom se přístup X nahradil Y mýlí, roste počet různých systémů a utilit obecně. Přísně vzato, Python nahrazuje jakýkoli turingovsky úplný jazyk. My, kteří jsme dříve dělali v C (ale vyrůstali na Basicu a Pascalu), pak v C++, jsme přešli na Python a následně třeba začínáme dělat s Rustem. Ale děláme věci, jaké se v C tenkrát nedělali a jsou zde spousty programátorů, kteří C neznají nebo ho v praxi nepoužili a jedou v tom s námi.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Bel Shamharoth 10. 11. 2020, 17:31:20
S dovolením bych se vrátil k rustu. Docela by mě zajímalo, jestli se ten jazyk vůbec ještě vyvýjí. Mě totiž příjde takový napůl mrtvý.

Proč? Před lety, když jsem ho zkoušel, tak jsem skončil na TcpListeneru, kterému nebylo možné nastavit timeout (a taková služba se prostě musí sestřelovat a tudíž je téměř nepoužitelná). Tenkrát jsem rust odložil jako jazyk ještě ve vývoji. Nic méně dívám se, že i po letech tahle základní funkcionalita pořád chybí. Exsituje sice crate net2, který vypadá, že by to mohl doplnit, ale tohle už mělo být dávno doplněné ve std. knihovně.

Neví někdo, jak je to s vývojem rustu? Tohle totiž moc živě nevypadá.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: qelurg 10. 11. 2020, 19:23:30
To nevím, ale má ošklivou syntaxi

Kód: [Vybrat]
fn vypis_obsah<T: MaObsah>(tvar: T) {
to mě odrazuje se o něj víc zajímat.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: registrovany_ava 10. 11. 2020, 20:50:42
S dovolením bych se vrátil k rustu. Docela by mě zajímalo, jestli se ten jazyk vůbec ještě vyvýjí. Mě totiž příjde takový napůl mrtvý.

Proč? Před lety, když jsem ho zkoušel, tak jsem skončil na TcpListeneru, kterému nebylo možné nastavit timeout (a taková služba se prostě musí sestřelovat a tudíž je téměř nepoužitelná). Tenkrát jsem rust odložil jako jazyk ještě ve vývoji. Nic méně dívám se, že i po letech tahle základní funkcionalita pořád chybí. Exsituje sice crate net2, který vypadá, že by to mohl doplnit, ale tohle už mělo být dávno doplněné ve std. knihovně.

Neví někdo, jak je to s vývojem rustu? Tohle totiž moc živě nevypadá.

Ano, Rust se "vyvýjí". https://blog.rust-lang.org/2020/05/15/five-years-of-rust.html
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: registrovany_ava 10. 11. 2020, 20:53:16
To nevím, ale má ošklivou syntaxi

Kód: [Vybrat]
fn vypis_obsah<T: MaObsah>(tvar: T) {
to mě odrazuje se o něj víc zajímat.

Možná se ti víc bude líbit novější

Kód: [Vybrat]
fn vypis_obsah(tvar: impl MaObsah) {
popř jaký zápis by se ti líbil víc?

Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: okalousek 11. 11. 2020, 00:32:55
Rust = Scala + C++ + statická správa paměti a skvělé nástroje (Cargo, kompilátor snad do všeho možného)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 11. 11. 2020, 08:15:29
To nevím, ale má ošklivou syntaxi

Kód: [Vybrat]
fn vypis_obsah<T: MaObsah>(tvar: T) {
to mě odrazuje se o něj víc zajímat.

Kód: [Vybrat]
fn vypis_obsah(tvar: impl MaObsah)
Hledáš zbytečně výmluvy. Vystup z komfortní zóny a nauč se pořádný jazyk.  :P

Edit: Sorry, už to psal ava...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 11. 11. 2020, 08:30:13
S dovolením bych se vrátil k rustu. Docela by mě zajímalo, jestli se ten jazyk vůbec ještě vyvýjí. Mě totiž příjde takový napůl mrtvý.

Proč? Před lety, když jsem ho zkoušel, tak jsem skončil na TcpListeneru, kterému nebylo možné nastavit timeout (a taková služba se prostě musí sestřelovat a tudíž je téměř nepoužitelná). Tenkrát jsem rust odložil jako jazyk ještě ve vývoji. Nic méně dívám se, že i po letech tahle základní funkcionalita pořád chybí. Exsituje sice crate net2, který vypadá, že by to mohl doplnit, ale tohle už mělo být dávno doplněné ve std. knihovně.

Neví někdo, jak je to s vývojem rustu? Tohle totiž moc živě nevypadá.

Tohle by nestačilo?

https://github.com/KizzyCode/timeout_io/blob/master/tests/acceptor.rs

Chápu argumenty typu "tohle by mělo být v základní knihovně", ale to "dávno" je dost závislé na tom, kolik lidí to trápí a kdo to může přidat...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Bel Shamharoth 11. 11. 2020, 11:38:02

Tohle by nestačilo?

https://github.com/KizzyCode/timeout_io/blob/master/tests/acceptor.rs
Chápu argumenty typu "tohle by mělo být v základní knihovně", ale to "dávno" je dost závislé na tom, kolik lidí to trápí a kdo to může přidat...

Tohle vypadá, že by i mohlo nějak fungovat, ale je to zase externí věc. Mě jde o to, že tohle se řešilo např. https://github.com/rust-lang/rust/issues/31615 (https://github.com/rust-lang/rust/issues/31615) v roce 2016. A jako tohle musí pálit každého, kdo píše síťovou službu. Přeci nemůžete zůstat viset na socketu dokud Vás nesestřelí.

Já nechci hanit rust, mě jen přijde, že sice žije komunita kolem jazyka, ale jazyk samotný už moc ne. Navíc, kdo vlastně za rustem stojí, Mozilla? To taky není moc perspektivní partner (v porovnání třeba s go a Googlem), servo je taky dead.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: okalousek 11. 11. 2020, 12:33:48

Tohle by nestačilo?

https://github.com/KizzyCode/timeout_io/blob/master/tests/acceptor.rs
Chápu argumenty typu "tohle by mělo být v základní knihovně", ale to "dávno" je dost závislé na tom, kolik lidí to trápí a kdo to může přidat...

Tohle vypadá, že by i mohlo nějak fungovat, ale je to zase externí věc. Mě jde o to, že tohle se řešilo např. https://github.com/rust-lang/rust/issues/31615 (https://github.com/rust-lang/rust/issues/31615) v roce 2016. A jako tohle musí pálit každého, kdo píše síťovou službu. Přeci nemůžete zůstat viset na socketu dokud Vás nesestřelí.

Já nechci hanit rust, mě jen přijde, že sice žije komunita kolem jazyka, ale jazyk samotný už moc ne. Navíc, kdo vlastně za rustem stojí, Mozilla? To taky není moc perspektivní partner (v porovnání třeba s go a Googlem), servo je taky dead.

Mnohdy je ta komunita důležitější než samotný jazyk.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: qelurg 11. 11. 2020, 13:00:33
To nevím, ale má ošklivou syntaxi

Kód: [Vybrat]
fn vypis_obsah<T: MaObsah>(tvar: T) {
to mě odrazuje se o něj víc zajímat.

Možná se ti víc bude líbit novější

Kód: [Vybrat]
fn vypis_obsah(tvar: impl MaObsah) {
popř jaký zápis by se ti líbil víc?

Prima, to by měl někdo na wikipedii opravit, protože pohled na tamtu hrůzu mě odradil se víc o Rust zajímat. Dneska už znám Cython a Rust tak nepřináší nic, co by mě motivovalo opustit důvěrně známé vody, moje potřeby jsou nyní plně uspokojeny.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: okalousek 11. 11. 2020, 13:33:46
Prima, to by měl někdo na wikipedii opravit, protože pohled na tamtu hrůzu mě odradil se víc o Rust zajímat. Dneska už znám Cython a Rust tak nepřináší nic, co by mě motivovalo opustit důvěrně známé vody, moje potřeby jsou nyní plně uspokojeny.

https://cs.wikipedia.org/wiki/Rust_(programovac%C3%AD_jazyk)#Uk%C3%A1zka_trait%C5%AF (https://cs.wikipedia.org/wiki/Rust_(programovac%C3%AD_jazyk)#Uk%C3%A1zka_trait%C5%AF)
Spokojen?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: qelurg 11. 11. 2020, 19:57:54
Já už jsem ztracený případ, ale třeba to jiným pomůže.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: okalousek 11. 11. 2020, 20:43:25
Já už jsem ztracený případ, ale třeba to jiným pomůže.

Zvídavá otázka: A jaký jazyk máte rád Vy (když ne Rust)?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: okalousek 11. 11. 2020, 22:56:06
I tak, většinou když se chci něco naučit o jazyce či jeho syntaxi základní knihovně tak se dívám na Rosetta Code a ne Wikipedii.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: qelurg 12. 11. 2020, 01:10:43
Já už jsem ztracený případ, ale třeba to jiným pomůže.

Zvídavá otázka: A jaký jazyk máte rád Vy (když ne Rust)?

viz 13:00
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: oss 12. 11. 2020, 07:23:51
Prima, to by měl někdo na wikipedii opravit, protože pohled na tamtu hrůzu mě odradil se víc o Rust zajímat. Dneska už znám Cython a Rust tak nepřináší nic, co by mě motivovalo opustit důvěrně známé vody, moje potřeby jsou nyní plně uspokojeny.

https://cs.wikipedia.org/wiki/Rust_(programovac%C3%AD_jazyk)#Uk%C3%A1zka_trait%C5%AF (https://cs.wikipedia.org/wiki/Rust_(programovac%C3%AD_jazyk)#Uk%C3%A1zka_trait%C5%AF)
Spokojen?

Ja som napriklad rad, ze Rust je konzervativny a stabilny, pren ako nizkourovnovy jazyk je to priam ziadane. Nechcem kazdy rok riesit nekompatibilne zmeny. Keby sa ma riadit haipom tak uz je z neho javascript.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: sofa_king 14. 11. 2020, 01:08:12
Rust bohuzel v posledni dobe nabobtnal do komplexity a samotne reseni lifetimu je na urovni hodne k posrani.

Vsichni kdo naskakali na rust train aby si neutrhli koule kvuli praci v C++ uz preskakali na programovaci jazyk Zig.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 14. 11. 2020, 08:35:05
Vsichni kdo naskakali na rust train aby si neutrhli koule kvuli praci v C++ uz preskakali na programovaci jazyk Zig.

A to tvrdí kdo, křišťálová koule, nebo Tiobe?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: anonacct 14. 11. 2020, 10:28:59
ZIG nikdo nepoužívá.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 14. 11. 2020, 10:51:54
ZIG nikdo nepoužívá.

No tak především by bylo záhodno na začátek uvést, že Zig je v zásadě jazyk pohybující se někde v kategorii C a ne C++, jak tvrdí kolega výše. Takže si s Rustem konkuruje opravdu jenom okrajově.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: AgentK 14. 11. 2020, 12:47:15
Mě RUST naprosto odrazuje syntaxí. Líbí se mi co to umí a jak to dělá, ale psát se mi v tom nechce. Podle mého názoru si hodně syntaxí ublížil v migraci lidí z C/C++, obzvlášť, když to je vlastně jeho cílovka.
Alespoň tak se mi to jeví.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 14. 11. 2020, 12:54:35
Mě RUST naprosto odrazuje syntaxí. Líbí se mi co to umí a jak to dělá, ale psát se mi v tom nechce. Podle mého názoru si hodně syntaxí ublížil v migraci lidí z C/C++, obzvlášť, když to je vlastně jeho cílovka.
Alespoň tak se mi to jeví.

Co konkrétně bys dělal jinak? Obávám se každopádně, že syntaxe je to nejmenší, co případného uživatele C bude trápit, ale můžu se mýlit. U C++ mám pocit, že to snad ani není jazyk, ale několik jazyků vedle sebe a leckterý uživatel C++ už mohl zkoušet Haskell nebo jiné funkcionální jazyky a syntaxi tolik řešit nebude.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: okalousek 14. 11. 2020, 12:56:29
Mě RUST naprosto odrazuje syntaxí. Líbí se mi co to umí a jak to dělá, ale psát se mi v tom nechce. Podle mého názoru si hodně syntaxí ublížil v migraci lidí z C/C++, obzvlášť, když to je vlastně jeho cílovka.
Alespoň tak se mi to jeví.

Kód v rustu má tendence se zašmodrchat, ale pokud se člověk snaží to psát hezky, tak je to v pohodě.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 14. 11. 2020, 14:38:08
Rust bohuzel v posledni dobe nabobtnal do komplexity a samotne reseni lifetimu je na urovni hodne k posrani.

Vsichni kdo naskakali na rust train aby si neutrhli koule kvuli praci v C++ uz preskakali na programovaci jazyk Zig.

No teda, koukal jsem se na něj, pár nápadů dobrejch, ale že by to byla konkurence Rustu...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: registrovany_ava 14. 11. 2020, 14:42:44
Mě RUST naprosto odrazuje syntaxí. Líbí se mi co to umí a jak to dělá, ale psát se mi v tom nechce. Podle mého názoru si hodně syntaxí ublížil v migraci lidí z C/C++, obzvlášť, když to je vlastně jeho cílovka.
Alespoň tak se mi to jeví.

Kód v rustu má tendence se zašmodrchat, ale pokud se člověk snaží to psát hezky, tak je to v pohodě.

Já mám opačnou zkušenost. Asi žádný jazyk mě zatím tolik nenutil kód rozšmodrchávat. Tím, že je naprosto striktní co se týče vlastnictví, sdílených a exkluzivních referencí, lifetimů, bezpečnosti přístupu z více vláken atp., člověka nutí kód předělávat, dokud tyhle věci nejsou jasné překladači, a jako vedlejší efekt většinou i programátorovi a čtenářům. Takže srovnatelnou funkcionalitu mi většinou v Rustu trvá déle implementovat, ale mám pak čistší, čitelnější a korektnější kód.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 14. 11. 2020, 16:42:47
Mě RUST naprosto odrazuje syntaxí. Líbí se mi co to umí a jak to dělá, ale psát se mi v tom nechce. Podle mého názoru si hodně syntaxí ublížil v migraci lidí z C/C++, obzvlášť, když to je vlastně jeho cílovka.
Alespoň tak se mi to jeví.

Kód v rustu má tendence se zašmodrchat, ale pokud se člověk snaží to psát hezky, tak je to v pohodě.

Já mám opačnou zkušenost. Asi žádný jazyk mě zatím tolik nenutil kód rozšmodrchávat. Tím, že je naprosto striktní co se týče vlastnictví, sdílených a exkluzivních referencí, lifetimů, bezpečnosti přístupu z více vláken atp., člověka nutí kód předělávat, dokud tyhle věci nejsou jasné překladači, a jako vedlejší efekt většinou i programátorovi a čtenářům. Takže srovnatelnou funkcionalitu mi většinou v Rustu trvá déle implementovat, ale mám pak čistší, čitelnější a korektnější kód.

+1
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: AgentK 14. 11. 2020, 17:28:15
Mě RUST naprosto odrazuje syntaxí. Líbí se mi co to umí a jak to dělá, ale psát se mi v tom nechce. Podle mého názoru si hodně syntaxí ublížil v migraci lidí z C/C++, obzvlášť, když to je vlastně jeho cílovka.
Alespoň tak se mi to jeví.

Co konkrétně bys dělal jinak? Obávám se každopádně, že syntaxe je to nejmenší, co případného uživatele C bude trápit, ale můžu se mýlit. U C++ mám pocit, že to snad ani není jazyk, ale několik jazyků vedle sebe a leckterý uživatel C++ už mohl zkoušet Haskell nebo jiné funkcionální jazyky a syntaxi tolik řešit nebude.

Možná, že jsem tomu nedal potřebný čas, právě proto, že se mi na první pohled nelíbí. :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Patek13 14. 11. 2020, 22:01:42
Sice je to trochu jiná kategorie, ale podle mě má velký potenciál Kotlin.
Při vydání .NET Core jsem dával velkou naději C#, ale dodnes nesplnil moje očekávání, hlavně kvůli oficiální podpoře multiplatformního GUI.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: okalousek 14. 11. 2020, 23:15:20
Sice je to trochu jiná kategorie, ale podle mě má velký potenciál Kotlin.
Při vydání .NET Core jsem dával velkou naději C#, ale dodnes nesplnil moje očekávání, hlavně kvůli oficiální podpoře multiplatformního GUI.

To ano, kotlin je vážně skvělý. Také si pohrávám se Scalou, doporučil bych se na ni také podívat, sdílí některé vlastnosti s rustem. Ale Kotlin a Scala jsou také úplně jiné kategorie.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 15. 11. 2020, 00:10:09
Sice je to trochu jiná kategorie, ale podle mě má velký potenciál Kotlin.
Při vydání .NET Core jsem dával velkou naději C#, ale dodnes nesplnil moje očekávání, hlavně kvůli oficiální podpoře multiplatformního GUI.
To ano, kotlin je vážně skvělý. Také si pohrávám se Scalou, doporučil bych se na ni také podívat, sdílí některé vlastnosti s rustem. Ale Kotlin a Scala jsou také úplně jiné kategorie.
Scala je fajn. Takové lepší F#.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: okalousek 15. 11. 2020, 09:51:39
Sice je to trochu jiná kategorie, ale podle mě má velký potenciál Kotlin.
Při vydání .NET Core jsem dával velkou naději C#, ale dodnes nesplnil moje očekávání, hlavně kvůli oficiální podpoře multiplatformního GUI.
To ano, kotlin je vážně skvělý. Také si pohrávám se Scalou, doporučil bych se na ni také podívat, sdílí některé vlastnosti s rustem. Ale Kotlin a Scala jsou také úplně jiné kategorie.
Scala je fajn. Takové lepší F#.
F# je .NETový dialekt ML, ne? Rust je inspirován OCamlem, ne?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 15. 11. 2020, 09:56:55
F# je .NETový dialekt ML, ne? Rust je inspirován OCamlem, ne?

Mimo jiné: https://doc.rust-lang.org/reference/influences.html

Spíš bych řekl, že "rodinou ML jazyků". Standard ML je třeba starší než Ocaml...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: okalousek 15. 11. 2020, 11:18:19
F# je .NETový dialekt ML, ne? Rust je inspirován OCamlem, ne?

Mimo jiné: https://doc.rust-lang.org/reference/influences.html

Spíš bych řekl, že "rodinou ML jazyků". Standard ML je třeba starší než Ocaml...

Ano. Jen jsem si to odvodil z toho, že Graydon napsal první kompilátor rustu právě v OCamlu. Teď zase dělá na Swiftu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Rike 28. 01. 2022, 23:38:43
Docela by mě zajímala ta budoucnost s odstupem času. Co se mi fakt nelíbí, že veliká část (co jsem zkoušel, tak většina) knihoven (crates) je pořád ve verzi 0.x, tedy neprodukční, zatímco si propagátoři leštěj ego na turbofish operátoru a jiných libůstkách. Jakoby se předháněli všichni v syntaktických vychytávkách a kašlalo se na ekosystém.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 29. 01. 2022, 00:03:49
Docela by mě zajímala ta budoucnost s odstupem času.
Já jsem na něj definitivně přesedlal. Všechno kompilované, rychlé, dělám v něm. K C++ se už nechci nikdy vrátit.

Jakoby se předháněli všichni v syntaktických vychytávkách a kašlalo se na ekosystém.
Pokud myslíš ekosysystém, jako tools, tak ten mi přijde fantastický. Pokud myslíš ekosystém, jako knihovny třetích stran, tak za to autoři jazyka dost dobře nemůžou. A nepřijde mi to tak hrozné.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 29. 01. 2022, 00:12:02
Docela by mě zajímala ta budoucnost s odstupem času. Co se mi fakt nelíbí, že veliká část (co jsem zkoušel, tak většina) knihoven (crates) je pořád ve verzi 0.x, tedy neprodukční
To ukáže čas :) Překladač i knihovny se momentálně živelně vyvíjí, ale v dohledné době se snad stabilizují a rozšíří. Podle mě má Rust našlápnuto slušně. C++ si s sebou z minulosti nese několik WTF, což Rustu docela nahrává. Ale křišťálovou kouli nemáme nikdo.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 29. 01. 2022, 08:19:59
Docela by mě zajímala ta budoucnost s odstupem času. Co se mi fakt nelíbí, že veliká část (co jsem zkoušel, tak většina) knihoven (crates) je pořád ve verzi 0.x, tedy neprodukční
To ukáže čas :) Překladač i knihovny se momentálně živelně vyvíjí, ale v dohledné době se snad stabilizují a rozšíří. Podle mě má Rust našlápnuto slušně. C++ si s sebou z minulosti nese několik WTF, což Rustu docela nahrává. Ale křišťálovou kouli nemáme nikdo.

Přiznám se, že mi ty 0.x verze taky vadí, ale podle mě to chce vzít případ od případu a zkoumat motivaci. Třeba někdo na sémantické verzování někdo neřeší nebo se bojí udržovat zpětnou kompatibilitu. Podle mě to je otázka času; zažili jsme to v Pythonu - do nějaké doby se většina držela verze 2 a do trojky se nikomu moc nechtělo a pak se to přehouplo a kdo váhal s přechodem na trojku, byl pomalu za hňupa.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 29. 01. 2022, 08:25:31
Jakoby se předháněli všichni v syntaktických vychytávkách a kašlalo se na ekosystém.
Pokud myslíš ekosysystém, jako tools, tak ten mi přijde fantastický. Pokud myslíš ekosystém, jako knihovny třetích stran, tak za to autoři jazyka dost dobře nemůžou. A nepřijde mi to tak hrozné.

Hrozné to není, pouze nepříjemné a budí to nedůvěru. Typicky se v diskusích uvádí rand jako příklad crate, kterou potřebují skoro všichni a pořád je ještě ve verzi 0.8.x. Kdyby neměl Rust rozumnou podporu závislostí, mohl by to být i technický problém, ne jen mentální, ale neradno ho podceňovat.

Zase je otázka, co by se stalo, kdyby nějaká podfinancovaná knihovna měla závažnou chybu a ohrozilo by to všechny závislé produkty. IMO by se hodilo udělat velkou akci a zapracovat na auditu a případné stabilizaci zásadních crates. Ale teď které to jsou, že...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 29. 01. 2022, 08:32:12
Docela by mě zajímala ta budoucnost s odstupem času. Co se mi fakt nelíbí, že veliká část (co jsem zkoušel, tak většina) knihoven (crates) je pořád ve verzi 0.x, tedy neprodukční, zatímco si propagátoři leštěj ego na turbofish operátoru a jiných libůstkách. Jakoby se předháněli všichni v syntaktických vychytávkách a kašlalo se na ekosystém.

Já si nemyslím, že na to "všichni kašlou". Pracuje se na všem možném a najednou. V poslední době mě potěšilo víc věcí - např. vydání produkční verze clap 3 (minor verze vychází snad obden a ubývá tam oprav chyb, takže mi přijde, že už to je dost stabilní a že ten release byl dobře načasovaný) a práce na integraci s Qt a KDE - GUI je jedna z největších bolístek Rustu, co se týče použitelnosti v různých oblastech. Nebo nom, který se zbavil před pár lety podle mě docela matoucích maker a přešel na funkce.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 29. 01. 2022, 08:57:16
Nebo nom, který se zbavil před pár lety podle mě docela matoucích maker a přešel na funkce.

Ještě upřesnění - ve verzi 5 přepracoval vnitřek na funkce, makra zůstala a ty funkce vnitřně používala a loňská verze 7 se maker zbavila úplně. Pokud se něco zásadního nezměnilo, hodilo by se zamakat na tutoriálech, ale knihovna jako taková je vyřešená.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Rike 29. 01. 2022, 11:48:24
Pokud myslíš ekosystém, jako knihovny třetích stran, tak za to autoři jazyka dost dobře nemůžou.
No, teoreticky můžou. Když půjdou cestou, jakou se vydalo třeba Deno, které ty nejpoužívanější, klíčové balíčky třetích stran prostě stáhlo pod svá křídla, díky čemuž máte jistotu, že je vyvíjí stejný tým, jako jádro, se stejnou kvalitou a nestane se, že uvíznou někde v závislostech jako opuštěné, neudržované.

...ale v dohledné době se snad stabilizují a rozšíří.
Už aby to bylo, protože když k tomu člověk přijde s odstupem dvou let, tak má pocit, že se dívá na něco docela jiného  ;)

...a práce na integraci s Qt a KDE - GUI je jedna z největších bolístek Rustu...
Má to nějaký jasně daný směr (resp. byl by odkaz na něco co už funguje)?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 29. 01. 2022, 12:06:23
...ale v dohledné době se snad stabilizují a rozšíří.
Už aby to bylo, protože když k tomu člověk přijde s odstupem dvou let, tak má pocit, že se dívá na něco docela jiného  ;)
Tak nevypadá to, že by Rust v nejbližší době chcípnul, zatím roste, dospívá a nejspíše si najde svou doménu nasazení (pokud se třeba více prosadí v jádře Linuxu — nedávno tam s ním začali experimentovat), kde pak zůstane “napořád” (jako COBOL nebo Fortran ve svých doménách nebo — modernější příklad — Go v DevOps apod.). Osobně doufám, že se pořádně rozšíří v embedded, tam taky skvěle pasuje.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Rike 29. 01. 2022, 12:35:28
Tak nevypadá to, že by Rust v nejbližší době chcípnul...
To jsem určitě nemyslel, spíš že se mění překotně, takže s odstupem času člověk přestává rozumět kódu, na který kouká  :)
Dá se vysledovat nějaký trend? Určité rozpaky budí lifetimes (u jednoduchých prográmků je jiný než statický docela zbytečná otrava), magie maker, magie návrhových vzorů, které se rozmohly... Dá se říct, k čemu bude jazyk konvergovat, nebo zda se zachová současná divočina?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 29. 01. 2022, 13:07:09
Tak nevypadá to, že by Rust v nejbližší době chcípnul...
Dá se vysledovat nějaký trend? […] Dá se říct, k čemu bude jazyk konvergovat, nebo zda se zachová současná divočina?
Moc konkrétně asi ne. Jen analogií, například Swift se ustálil po několika letech (ABI apod.). Syntax se nejspíš bude měnit (rozšiřovat), ale to tak bývá u nových jazyků, viz Swift nebo Julia.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 29. 01. 2022, 16:27:48
...a práce na integraci s Qt a KDE - GUI je jedna z největších bolístek Rustu...
Má to nějaký jasně daný směr (resp. byl by odkaz na něco co už funguje)?

Zcela obecně - existují nějaké velké GUI frameworky - zejména Qt a Gtk+, za nimi o něco méně významné Fltk a wxWidgets. S Qt je potíž, jelikož je to psané na míru C++ a jeho OOP vlastnostem. Výborně to funguje ve spojení třeba s Pythonem, kde je velká míra kompatibility OOP modelu - násobná dědičnost apod. Celkem blbě to funguje u výrazně jiných jazyků, jako je třeba Haskell nebo Rust. Jo, pořád se na tom dělá a třeba to nějak ti lidi dopilují.

Gtk je psané v C a bindingy pro ostatní jazyky včetně Rustu se dělají poměrně snadno.

Fltk zblízka neznám, přijde mi primitivnější, ale to může být i výhoda. Bindingy jsou aktivně vyvíjené, na rozdíl třeba od wxWidgets.

Pak existují specialitky jako druid, Orbtk a egui. Podle mě to je všechno zatím spíš hračka, ale možná se něco změnilo.

Doporučuju zaměřit se na relm, resp. gtk-rs, to jsou IMO nejvymakanější a nejpoužívanější řešení pro Rust. V prvním případě pokud chceš mít vše definované programově a idiomaticky. Ve druhém případě si můžeš UI naklikat v Glade, ale spíš tíhnu k Relmu. BTW existuje verze i pro Gtk+ 4 (relm4).

Svět GUI je roztříštěný všude, ale zvlášť v Rustu mi to Gtk+, resp. spíš Relm přijde jako jasná volba.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: anonacct 29. 01. 2022, 19:29:56
I když je Gtk psané v C tak používá dědičnost, takže bindovat Qt nebo Gtk je v podstatě to samé.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 29. 01. 2022, 19:42:38
I když je Gtk psané v C tak používá dědičnost, takže bindovat Qt nebo Gtk je v podstatě to samé.
GTK sice dědičnost má, ale vlastní, nepoužívá na to prostředky jazyka. Na rozdíl od Qt. Takže to není vůbec to samé.

A nebo na to jdi z druhé strany. Na GTK je binding (https://en.wikipedia.org/wiki/List_of_language_bindings_for_GTK) z každého myslitelného jazyka. Můžeš to porovnat s bindingy (https://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_5) do Qt a udělat si názor sám.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: ondra05 29. 01. 2022, 20:16:45
...a práce na integraci s Qt a KDE - GUI je jedna z největších bolístek Rustu...
Má to nějaký jasně daný směr (resp. byl by odkaz na něco co už funguje)?

Zcela obecně - existují nějaké velké GUI frameworky - zejména Qt a Gtk+, za nimi o něco méně významné Fltk a wxWidgets. S Qt je potíž, jelikož je to psané na míru C++ a jeho OOP vlastnostem. Výborně to funguje ve spojení třeba s Pythonem, kde je velká míra kompatibility OOP modelu - násobná dědičnost apod. Celkem blbě to funguje u výrazně jiných jazyků, jako je třeba Haskell nebo Rust. Jo, pořád se na tom dělá a třeba to nějak ti lidi dopilují.

Gtk je psané v C a bindingy pro ostatní jazyky včetně Rustu se dělají poměrně snadno.

Fltk zblízka neznám, přijde mi primitivnější, ale to může být i výhoda. Bindingy jsou aktivně vyvíjené, na rozdíl třeba od wxWidgets.

Pak existují specialitky jako druid, Orbtk a egui. Podle mě to je všechno zatím spíš hračka, ale možná se něco změnilo.

Doporučuju zaměřit se na relm, resp. gtk-rs, to jsou IMO nejvymakanější a nejpoužívanější řešení pro Rust. V prvním případě pokud chceš mít vše definované programově a idiomaticky. Ve druhém případě si můžeš UI naklikat v Glade, ale spíš tíhnu k Relmu. BTW existuje verze i pro Gtk+ 4 (relm4).

Svět GUI je roztříštěný všude, ale zvlášť v Rustu mi to Gtk+, resp. spíš Relm přijde jako jasná volba.

No, idiomaticky... Ten GObject je docela fuj. V Rustu na to alespoň jsou nějaká makra, ale i tak.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 11. 2022, 11:10:52
Rust má konečně v nejnovější verzi GAT. Že jim to ale trvalo.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Zdenek Tomes 04. 11. 2022, 12:37:35
Rust má konečně v nejnovější verzi GAT. Že jim to ale trvalo.

Dalsi verze Rustu se tedy bude jmenovat Haskell? :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 04. 11. 2022, 13:19:59
Rust má konečně v nejnovější verzi GAT. Že jim to ale trvalo.

Dalsi verze Rustu se tedy bude jmenovat Haskell? :)

Ano, hned poté, co bude v Haskellu nějaký jiný použitelný OSS produkt vedle XMonadu a asi dvou dalších, na které si teď hned nevzpomenu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 11. 2022, 14:08:47
Rust má konečně v nejnovější verzi GAT. Že jim to ale trvalo.
Dalsi verze Rustu se tedy bude jmenovat Haskell? :)
Ne, protože Haskell GAT nemá, nikdy mít nebude a ony ostatně vůbec nesouvisí s FP. Původně pocházejí ze Swiftu, Rust je prostě čórnul.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 11. 2022, 14:11:03
Rust má konečně v nejnovější verzi GAT. Že jim to ale trvalo.
Dalsi verze Rustu se tedy bude jmenovat Haskell? :)
Ano, hned poté, co bude v Haskellu nějaký jiný použitelný OSS produkt vedle XMonadu a asi dvou dalších, na které si teď hned nevzpomenu.
https://en.wikipedia.org/wiki/Category:Free_software_programmed_in_Haskell
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 04. 11. 2022, 15:23:19
Dalsi verze Rustu se tedy bude jmenovat Haskell? :)
Ano, hned poté, co bude v Haskellu nějaký jiný použitelný OSS produkt vedle XMonadu a asi dvou dalších, na které si teď hned nevzpomenu.
https://en.wikipedia.org/wiki/Category:Free_software_programmed_in_Haskell

Ha, přes 20:

Agda a Idris jsou specialitky, ale OK.
Tooling pro Haskell snad ani nemá smysl počítat.
Darcs je pomalý a chybový (a zbytečný, stejně všichni jedou na Gitu).
House je mrtvější než Hurd.
Atd.

Za řeč stojí Pandoc a QuickCheck (coby inspirace pro ostatní jazyky, které to reimplementovaly). A XMonad, který už roky používám. S Agdou a Idrisem jsme na pěti. To je hodně slabé.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 04. 11. 2022, 15:37:22
Dalsi verze Rustu se tedy bude jmenovat Haskell? :)
Ano, hned poté, co bude v Haskellu nějaký jiný použitelný OSS produkt vedle XMonadu a asi dvou dalších, na které si teď hned nevzpomenu.
https://en.wikipedia.org/wiki/Category:Free_software_programmed_in_Haskell

Ha, přes 20:

Agda a Idris jsou specialitky, ale OK.
Tooling pro Haskell snad ani nemá smysl počítat.
Darcs je pomalý a chybový (a zbytečný, stejně všichni jedou na Gitu).
House je mrtvější než Hurd.
Atd.

Za řeč stojí Pandoc a QuickCheck (coby inspirace pro ostatní jazyky, které to reimplementovaly). A XMonad, který už roky používám. S Agdou a Idrisem jsme na pěti. To je hodně slabé.

Navzdory tomu, jak ho nikdo nepoužívá, a přitom se o něm furt mluví a furt ho někdo používá...

Já jsem Haskellu vděčen hlavně za změnu mindsetu. Seznámil jsem se s ním, napsal jeden nebo dva projekty, a od té doby se na všechny rádoby moderní jazyky jako C#, Python, Javascript dívám skrz prsty. (Zvláště C#, ten je úplně zbytečnej.) Už jen z tohoto důvodu si zaslouží svou slávu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 11. 2022, 15:40:16
S Agdou a Idrisem jsme na pěti. To je hodně slabé.
Pro Idris to už dávno ani neplatí.

Je třeba mít na paměti, že Haskell je převážně akademický jazyk sloužící pro bádání nad FP, typovými systémy apod. Pro praxi — když už chce člověk čisté FP — se hodí spíše PureScript nebo ten Idris s nějakým rozumným backendem (Chez?).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 11. 2022, 15:44:39
Já jsem Haskellu vděčen hlavně za změnu mindsetu. [...] Už jen z tohoto důvodu si zaslouží svou slávu.
Слава Гаскелі :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 04. 11. 2022, 20:59:50
https://en.wikipedia.org/wiki/Category:Free_software_programmed_in_Haskell

Ha, přes 20:

Agda a Idris jsou specialitky, ale OK.
Tooling pro Haskell snad ani nemá smysl počítat.
Darcs je pomalý a chybový (a zbytečný, stejně všichni jedou na Gitu).
House je mrtvější než Hurd.
Atd.

Za řeč stojí Pandoc a QuickCheck (coby inspirace pro ostatní jazyky, které to reimplementovaly). A XMonad, který už roky používám. S Agdou a Idrisem jsme na pěti. To je hodně slabé.

Navzdory tomu, jak ho nikdo nepoužívá, a přitom se o něm furt mluví a furt ho někdo používá...

Já jsem Haskellu vděčen hlavně za změnu mindsetu. Seznámil jsem se s ním, napsal jeden nebo dva projekty, a od té doby se na všechny rádoby moderní jazyky jako C#, Python, Javascript dívám skrz prsty. (Zvláště C#, ten je úplně zbytečnej.) Už jen z tohoto důvodu si zaslouží svou slávu.

V pohodě, můj respekt má. Nicméně když jsem se v něm hrabal já, furt někdo psal nějaké popisy, co vlastně znamená monáda. Autorům těchto "pure FP" jazyků přijde programování s efekty jako zlo, které je třeba zavřít někam do klece, aby nezničilo svět. A jelikož většina programů furt nějaké "vedlejší efekty" páchá, přijde mi to dost nepraktické. Rust tímhle netrpí (má taky svoje podivnosti, ale poměr bolesti a užitku je snesitelný pro větší množinu vývojářů). Zároveň obsahuje dost poměrně zajímavých a silných abstrakcí a možností vyjádření. Ale třeba i ten Python se vyvíjí zajímavým způsobem; je složitější, ale expresivnější a umožňuje psát spolehlivější kód než minulé verze.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 11. 2022, 21:15:12
Nicméně když jsem se v něm hrabal já, furt někdo psal nějaké popisy, co vlastně znamená monáda.
Tahle doba už pominula, teď už to asi každý ví, jelikož pronikly do mnoha moderních jazyků. Navíc tyhle vesměs zbytečně “popisy” zastínily jiné vlastnosti FP.

Zrovna Haskell není nic světoborného, je to na hraní pro akademiky, ale různé praktičtější (více či méně) klony Haskellu umožňují psát elegantní a efektivní kód (například v Idrisu jdou bez problémů používat efekty, aniž by člověk psal — na povrchu — funkcionálně, je tam pro to spousta syntaktického cukru, mnohem více než v Haskellu).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 11. 2022, 21:22:06
Rust tímhle netrpí […] Zároveň obsahuje dost poměrně zajímavých a silných abstrakcí a možností vyjádření.
Jako co třeba (oproti jiným moderním jazykům)? Poslední dobou v Rustu píšu docela hodně (a idiomaticky, aspoň podle “moudrých” knih), ale nic extra na něm nevidím. Jediná zásadní výhoda (pro některé projekty, jinde je to jedno) je, že nemá plně automatický GC, ale když napíšu stejný kód v Julii bez použití měnitelných struktur, tak se taky na haldě skoro nic nealokuje a výsledek je stejně rychlý.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 04. 11. 2022, 21:22:56
Autorům těchto "pure FP" jazyků přijde programování s efekty jako zlo, které je třeba zavřít někam do klece, aby nezničilo svět. A jelikož většina programů furt nějaké "vedlejší efekty" páchá, přijde mi to dost nepraktické.
Nejen autorům. Součástí té změny mindsetu bylo právě přijetí této zásady. Od té doby se na veškerej kód i v "normálních" imperativních jazycích dívám jako pure/mající efekty. A čistě subjektivně mi přijde, že to dobře slouží.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 11. 2022, 21:34:52
Nejen autorům. Součástí té změny mindsetu bylo právě přijetí této zásady. Od té doby se na veškerej kód i v "normálních" imperativních jazycích dívám jako pure/mající efekty.
S tímto v imperativním světě přišel už Fortran.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 05. 11. 2022, 09:20:15
Otázka je, co přesně Vás zajímá.

Stane se někdy Rust jedním ze tří nejpoužívanějších jazyků? Dost možná ne. Rust sice umožňuje zajímavé věci, ale taky něco od programátora vyžaduje (lifetimes), a pro spoustu věcí se to nevyplatí.

Jak se bude na pracovním trhu dařit programátorovi v Rustu? Dnes je sice pracovních míst pro Rusťáky sice málo, ale taky je málo Rusťáků, takže finančně to nebude špatné. Nebál bych se, že by nešlo se tím uživit. Možná to bude práce na dálku, protože ne v každém městě najdeme něco on-site; v ČR aktuálně nevím o ničem mimo Prahu. Mainstreamovější jazyk bude mít výhodu, že budete mít větší volbu, na čem chcete pracovat.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 11. 2022, 10:31:14
Rust sice umožňuje zajímavé věci, ale taky něco od programátora vyžaduje
Překladač se naštěstí za ty roky podstatně zlepšil, je výrazně sofistikovanější a už tolik nebuzeruje.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 05. 11. 2022, 11:37:21
To věřím. Věřím i tomu, že se ještě zlepší. Nevěřím tomu, že by to z hlediska starání se o reference bylo u netriviálních projektů podobně bezstarostné jako jazyky s GC. Čekám, že si Rust ukrojí něco z C a C++ (tam IMHO programátor musí udělat podobnou úvahu jako u borrow checkeru, akorát nemá formální zápis, který by kompilátor zvládl zkontrolovat). A ano, najdete případy, kdy někdo do Rustu bude přepisovat kód v Pythonu, JS a dalších jazycích. Těmto jazykům ale Rust nejspíš moc neukrojí, spíše se přepíší části kódu, kde to bude dávat ekonomický smysl (nároky na rychlost, snadnost implementace…). Ale tam bude Rust spíše konkurovat jiným jazykům (C, Go apod.), do kterých by šly tyto části přepsat.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Petr P 05. 11. 2022, 15:06:54
Já nějak moc nevidím přímos.
Ve své sadě mám C, C++, C# a python...
Rust oproti C je omezující. Možná se dá postavit oproti C++, ale co z toho?
Několikrát jsem se tím zkoušel zabývat, ale sytaxe mi přijde udělaná podle pravidla - hlavně se vymezit.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 05. 11. 2022, 15:46:19
Bohudík Rust není jazyk budoucnosti. Neberu mu jeho přínos, ale C nenahradí, C++ i přes svoje problémy se drží a popravdě, není to tak špatný jazyk. Daleko zajímavější mi přijdou různé "DSL" jazyky jako K/J, Forth, Joy, Factor, Erlang. Konrétně Factor mi přijde jako zvláštní mix Smalltalku a Erlangu. Klobouk dolů před jeho tvůrcem.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: linuxak 05. 11. 2022, 16:15:49
Bohudík Rust není jazyk budoucnosti. Neberu mu jeho přínos, ale C nenahradí
Jistě, Rust nemůže C nahradit, C má svoje nezastupitelné místo třeba v Linux kernelu. Oh, wait.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 05. 11. 2022, 16:25:04
Bohudík Rust není jazyk budoucnosti. Neberu mu jeho přínos, ale C nenahradí
Jistě, Rust nemůže C nahradit, C má svoje nezastupitelné místo třeba v Linux kernelu. Oh, wait.
Jestli narážíte na to, že se před nějakou dobou něco dostalo do kernelu, tak to pořád nic neznamená. C se nezbavíte z historických a pragmatických důvodů ještě desítky let. A až se to stane, třeba změnou technologie/paradigmatu třeba až na úrovni toho, jak pracujeme s železem, tak už bude Rust dávno za zenitem. C++ je sice z mnoha důvodů bestie, ale tohle se stane každému jazyku, co je umožňuje programovat tak nízko a vysoko nad železem a navíc je  zpětně kompatibilní cca 40 let (o jakési kompatibilitě s C ani nemluvě). Moc nechápu proč se nepoužívá více Ada, která toho umí opravdu dost (+ SPARK). Spíše jen historická smůla. Ale až dotáhnou package manager, třeba se to zvedne. Daleko větší mínění mám o Go, které jsem léta ignoroval i přes to, že Pike a spol. jsou pro mě autority..
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: linuxak 05. 11. 2022, 16:40:31
Jestli narážíte na to, že se před nějakou dobou něco dostalo do kernelu, tak to pořád nic neznamená.
Rust je prvním jazykem, který se do kernelu dostal (pro informaci, C++ to nedokázalo). Linus i ostatní kernel vývojáři vidí jeho přínosy oproti C, proto má Rust cestu do kernelu otevřenou. Popravdě je jen otázka času, kdy Rust (nebo nějaký jeho nástupce) v kernelu úplně nahradí C, protože garance, které dává Rust, hlavně ohledně bezpečnosti, v C nikdy nebudou a tohle prostě nejde ignorovat. Nebude to za rok, nebude to možná ani za 10 let, ale vývoj je jasně daný, C se postupně stane legacy jazykem, ve kterém se v kernelu bude kód jen udržovat a postupně nahrazovat Rustem (nebo něčím lepším, než Rust). Ano, cesta k tomu je ještě dlouhá, ale stane se to.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: a6b 05. 11. 2022, 17:14:21
Jestli narážíte na to, že se před nějakou dobou něco dostalo do kernelu, tak to pořád nic neznamená.
Rust je prvním jazykem, který se do kernelu dostal (pro informaci, C++ to nedokázalo). Linus i ostatní kernel vývojáři vidí jeho přínosy oproti C, proto má Rust cestu do kernelu otevřenou. Popravdě je jen otázka času, kdy Rust (nebo nějaký jeho nástupce) v kernelu úplně nahradí C, protože garance, které dává Rust, hlavně ohledně bezpečnosti, v C nikdy nebudou a tohle prostě nejde ignorovat. Nebude to za rok, nebude to možná ani za 10 let, ale vývoj je jasně daný, C se postupně stane legacy jazykem, ve kterém se v kernelu bude kód jen udržovat a postupně nahrazovat Rustem (nebo něčím lepším, než Rust). Ano, cesta k tomu je ještě dlouhá, ale stane se to.


jine kernely napr. L4 jsou napsany v C++, samozrejme bez vyjimek
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 05. 11. 2022, 18:02:49
Rust v kernelu pohledem skeptika: Není to významné a dlouho nebude. IIRC tam Rust zdaleka nelze použít na cokoli, protože kernel podporuje velké množství platforem, ne všechny umí rustc. Takže využití bude spíše na drivery, kde omezená multiplatformnost není překážkou.

Rust v kernelu pohledem optimisty: Naznačuje to, že nejspíš by dnes podobný projekt vznikal v Rustu. Dříve nebo později si Rust cestu najde jako hlavní jazyk kernelu – archaické platformy budou dříve či později nepodporované, některé nové platformy mohou naopak získat podporu v rustc.

Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: linuxak 05. 11. 2022, 18:29:19
Rust v kernelu pohledem skeptika: Není to významné a dlouho nebude. IIRC tam Rust zdaleka nelze použít na cokoli, protože kernel podporuje velké množství platforem, ne všechny umí rustc. Takže využití bude spíše na drivery, kde omezená multiplatformnost není překážkou.
Tohle se aktivně řeší, brzo bude Rust v gcc, takže problém s (ne)podporou velkého množství platforem zmizí: https://devclass.com/2022/07/12/rust-gcc-front-end-approved-by-steering-committee-beta-expected-in-gcc-13/
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: hknmtt 05. 11. 2022, 20:21:41
Je podle Vás Rust jazyk budoucnosti? Případně, jaké jsou pro a proti a jaké budou klíčové milníky pro Rust? Použití Rustu narozdíl od Go tolik neroste, jaký to má podle Vás důvod a může se to v horizontu 1-2 let změnit?

Podla mna buducnost je Go, Zig, Java a JavaScript. Rust je kult-ovy jazyk s extremne exotickou syntaxou a prilist vybaca mimo normy programovacich jazykov. Takze nie, buducnost to urcite nie je. Nehovorim ze zanikne, ale ostane niche jazykom tak ako je nim aj teraz.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 11. 2022, 22:35:00
protože garance, které dává Rust, hlavně ohledně bezpečnosti, v C nikdy nebudou a tohle prostě nejde ignorovat.
Přesně.
C dlouhou dobu mělo obsazenou niku, do které žádný jiný jazyk nezasahoval. Nejblíž tomu mělo Go - to ale mělo GC a nemělo garance. Od okamžiku kdy přišel Rust je C mrtvá záležitost.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 11. 2022, 22:40:23
Zig,
Máš s ním nějaké konkrétní zkušenoti? V jakém je stavu? Na co je použitelný?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 06. 11. 2022, 00:25:16
Tohle se aktivně řeší, brzo bude Rust v gcc, takže problém s (ne)podporou velkého množství platforem zmizí: https://devclass.com/2022/07/12/rust-gcc-front-end-approved-by-steering-committee-beta-expected-in-gcc-13/
OK, superz to může větší nasazení do kernelu o nějaký ten rok (možná dekádu) urychlit…
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 06. 11. 2022, 00:41:39
Podla mna buducnost je Go, Zig, Java a JavaScript.

Ve které oblasti? Je-li řeč třeba o webu, je to klidně možné. (Asi bych udělal ten seznam trochu jinak, ale Rust tam asi nebude v top 5.) Je-li řeč o embedded, tam asi bude situace o dost jiná.

Rust je kult-ovy jazyk s extremne exotickou syntaxou a prilist vybaca mimo normy programovacich jazykov

Zrovna syntaxe mi přijde celkem konzervativní. Částečně odpovídá C (ale vynechává závorky u řídicích struktur), lambdy má z Ruby, a i další prvky syntaxe mi přijdou celkem konzervativní a známé odjinud. Jo, některá klíčová slova se jmenují trochu jinak.

Největší challenge mi přijde správa paměti, pro lidi zvyklé na GC to asi bude znamenat trochu změnu paradigmatu. Zajímavé bylo též pochopit fat pointery (zejména v kombinaci a traity), ale to typicky není brzda na začátku.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: L.. 06. 11. 2022, 07:51:40
Podla mna buducnost je Go, Zig, Java a JavaScript.

Co se týče ostatních nevím, ale místo JavaScriptu bych dal Typescript. JS nemá statické typování a tak v něm vyvíjet větší aplikace je dost neefektivní.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 06. 11. 2022, 09:34:08
Zig,
Máš s ním nějaké konkrétní zkušenoti? V jakém je stavu? Na co je použitelný?
Nedávno tu někdo psal o zkušenostech s programováním embeded Rust vs Zig (1:0 pro Zig). Zig má skvělý toolchain. Dávám mu také velkou šanci prorazit právě tam, kde se cpe Rust. Dále jazyk D má spoustu vlastností, které má Rust. Opět, neměl zatím tolik štěstí (čti marketing).

Problém jazyků jako Rust je, že mi sice dávají nějaké garance, ale cena za to je dost vysoká. Navíc, pokud se nepletu, nemají formální důkaz a navíc nemají ani standard.

Nakonec bych si přečetl tady Linuse: https://lkml.org/lkml/2022/9/19/1105#1105.php
, když už se tu stále omílá kernel Linuxu.

And the *reality* is that there are no absolute guarantees.  Ever. The
"Rust is safe" is not some kind of absolute guarantee of code safety.
Never has been. Anybody who believes that should probably re-take
their kindergarten year, and stop believing in the Easter bunny and
Santa Claus
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 06. 11. 2022, 10:38:58
Zig,
Máš s ním nějaké konkrétní zkušenoti? V jakém je stavu? Na co je použitelný?
Nedávno tu někdo psal o zkušenostech s programováním embeded Rust vs Zig (1:0 pro Zig). Zig má skvělý toolchain. Dávám mu také velkou šanci prorazit právě tam, kde se cpe Rust. Dále jazyk D má spoustu vlastností, které má Rust. Opět, neměl zatím tolik štěstí (čti marketing).

Problém D je, že si zachovává přístup C++ - přidávání dalších a dalších vlastností, zatímco autoři Rustu se rozhodli to udělat jinak. D je mrtvý jazyk ne proto, že neměl dobrý marketing, ale že autoři neměli odvahu udělat tu změnu pořádně.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 06. 11. 2022, 10:41:39
Nedávno tu někdo psal o zkušenostech s programováním embeded Rust vs Zig (1:0 pro Zig). Zig má skvělý toolchain. Dávám mu také velkou šanci prorazit právě tam, kde se cpe Rust.

Zig je lepší C, ale většina programátorů podle mě nechce psát aplikace v lepším C. Nedovedu si představit jeho nasazení v mnoha oblastech, kam se "cpe" Rust.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 11. 2022, 11:16:21
Moc nechápu proč se nepoužívá více Ada, která toho umí opravdu dost (+ SPARK).
To by bylo hezké, ale obávám se, že okénko příležitosti pro Adu je už pryč :(
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 11. 2022, 11:22:49
Daleko větší mínění mám o Go, které jsem léta ignoroval i přes to, že Pike a spol. jsou pro mě autority.
Různé Pikovy přednášky a prezentace jsou skvělé, jeho úhel pohledu je často poněkud specifický, člověk se pak sám na některé věci začne dívat jinak.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: a6b 06. 11. 2022, 11:37:25
Daleko větší mínění mám o Go, které jsem léta ignoroval i přes to, že Pike a spol. jsou pro mě autority.
Různé Pikovy přednášky a prezentace jsou skvělé, jeho úhel pohledu je často poněkud specifický, člověk se pak sám na některé věci začne dívat jinak.

plan9 a 9front atd. jsou skvele projekty.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 06. 11. 2022, 11:45:35
Zig,
Máš s ním nějaké konkrétní zkušenoti? V jakém je stavu? Na co je použitelný?
Nedávno tu někdo psal o zkušenostech s programováním embeded Rust vs Zig (1:0 pro Zig). Zig má skvělý toolchain. Dávám mu také velkou šanci prorazit právě tam, kde se cpe Rust. Dále jazyk D má spoustu vlastností, které má Rust. Opět, neměl zatím tolik štěstí (čti marketing).

Problém D je, že si zachovává přístup C++ - přidávání dalších a dalších vlastností, zatímco autoři Rustu se rozhodli to udělat jinak.

Prošel jste si nějaké informace o tomto jazyku detailně? Viděl jste nějaké video z dconf? Neříkám, že jsem nějaký Rust expert, ale nutně jsem toho asi viděl více protože hype. Mrkněte na D.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: linuxak 06. 11. 2022, 12:27:58
Prošel jste si nějaké informace o tomto jazyku detailně? Viděl jste nějaké video z dconf? Neříkám, že jsem nějaký Rust expert, ale nutně jsem toho asi viděl více protože hype. Mrkněte na D.
D není konkurencí Rustu. Ve skutečnosti Rust ve své doméně žádnou konkurenci nemá, protože paměťovou bezpečnost bez garbage collectoru žádný jiný jazyk nenabízí. Tohle je hlavní selling point Rustu a důvod, proč je kolem Rustu takový hype a proč se docela úspěšně prosazuje. Zjevně je na trhu poptávka po paměťově bezpečném jazyku bez garbage collectoru. Srovnání Rustu s C/D/Zig moc nedává smysl, protože pokud někdo požaduje paměťovou bezpečnost bez garbage collectoru, vezme Rust, nemá jinou volbu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 06. 11. 2022, 13:35:19
Prošel jste si nějaké informace o tomto jazyku detailně? Viděl jste nějaké video z dconf? Neříkám, že jsem nějaký Rust expert, ale nutně jsem toho asi viděl více protože hype. Mrkněte na D.
D není konkurencí Rustu. Ve skutečnosti Rust ve své doméně žádnou konkurenci nemá, protože paměťovou bezpečnost bez garbage collectoru žádný jiný jazyk nenabízí. Tohle je hlavní selling point Rustu a důvod, proč je kolem Rustu takový hype a proč se docela úspěšně prosazuje. Zjevně je na trhu poptávka po paměťově bezpečném jazyku bez garbage collectoru. Srovnání Rustu s C/D/Zig moc nedává smysl, protože pokud někdo požaduje paměťovou bezpečnost bez garbage collectoru, vezme Rust, nemá jinou volbu.

Taky. Ale i to, že vývojáři Rustu vědí, že popularita záleží mimo jiné i na toolingu a lidech. Má D něco jako Cargo? Něco jako Rustup? A pokud ano, tak jak dlouho? Má třeba něco jako https://wiki.mozilla.org/Areweyet ? Jaké jsou referenční FOSS projekty v D? Co jsem našel a stálo za řeč, byly 5-8 let mrjvé repozitáře.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 06. 11. 2022, 15:16:18
Prošel jste si nějaké informace o tomto jazyku detailně? Viděl jste nějaké video z dconf? Neříkám, že jsem nějaký Rust expert, ale nutně jsem toho asi viděl více protože hype. Mrkněte na D.
D není konkurencí Rustu. Ve skutečnosti Rust ve své doméně žádnou konkurenci nemá, protože paměťovou bezpečnost bez garbage collectoru žádný jiný jazyk nenabízí. Tohle je hlavní selling point Rustu a důvod, proč je kolem Rustu takový hype a proč se docela úspěšně prosazuje. Zjevně je na trhu poptávka po paměťově bezpečném jazyku bez garbage collectoru. Srovnání Rustu s C/D/Zig moc nedává smysl, protože pokud někdo požaduje paměťovou bezpečnost bez garbage collectoru, vezme Rust, nemá jinou volbu.

Taky. Ale i to, že vývojáři Rustu vědí, že popularita záleží mimo jiné i na toolingu a lidech. Má D něco jako Cargo? Něco jako Rustup? A pokud ano, tak jak dlouho? Má třeba něco jako https://wiki.mozilla.org/Areweyet ? Jaké jsou referenční FOSS projekty v D? Co jsem našel a stálo za řeč, byly 5-8 let mrjvé repozitáře.

Hledáš takto špatně schválně?
https://code.dlang.org/
https://dlang.org/orgs-using-d.html
https://www.youtube.com/c/TheDLanguageFoundation/playlists
K tématu: https://dconf.org/2020/online/index.html#walter

Python a Rust opravdu nejsou jedinné použitelné jazyky ve svoji doméně. Mně osobně čím dál tím leze na nervy jejich evangelizace.


O co se D znažilo byla nějaká kompatibilita a konzumace C++ projektů... tam si Rust prostě ulevil. Dle názoru jiných to stálo D týmu dost energie a je to velké sousto. Podobně se o to snaží Google se svým Carbonem.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: hknmtt 06. 11. 2022, 16:01:10
len drobna poznamka k rustu https://www.youtube.com/watch?v=ZvskDoP09Ao&t=686s
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 11. 2022, 16:12:00
Problém jazyků jako Rust je, že mi sice dávají nějaké garance, ale cena za to je dost vysoká.
Nějaká garance za X cenu je stále víc jak žádná garance za X cenu. Rust versus C.


Mrkněte na D.
Já na něj nejen koukal, ale dokonce jsem ho používal. Tlačí se do niky být jednodužší (něco jako Java) ale co se bezpečnosti týče tak se prakticky (krom pár drobností) moc nesnaží. Napsal jsem projekt a šel dál. IMHO nemá budoucnost.
- D lang má příjemnou syntaxi jako Java
- rychlej kompiler, rychlej start
- pár vychytávek (vzpomínám si na switch); plus nějaké metaprogramování
- kompiler je uzavřený (pokud se od té doby něco nezměnilo)
- málo knihoven (to mu ale nejde moc vyčítat)
- minimální garance


Mně osobně čím dál tím leze na nervy jejich evangelizace.
To je ale tvůj problém. A je to tak dobře, protože stále budou zákazníci, kteří budou poptávat programátory pro C/C++ legacy kód.


Python a Rust opravdu nejsou jedinné použitelné jazyky ve svoji doméně.
[...]
O co se D znažilo byla nějaká kompatibilita a konzumace C++ projektů... tam si Rust prostě ulevil. Dle názoru jiných to stálo D týmu dost energie a je to velké sousto. Podobně se o to snaží Google se svým Carbonem.

Ano, pokud Dlang se snaží o kompatabilitu C++ projektů, (btw Rust to umí do určité míry taky) tak to je určitě záslužná věc, jenže - ocenil to někdo?


Jen pro pořádek: Rust cílí na dvě věci: garance a rychlost. Tomu je podřízena syntaxe i náročnost učení se. Který jazyk je tomu konkurencí? Já o žádném nevím.
D nemá garance
Haskel je pomalej
Zig neznám, a přijde mi, že se zatím potácí mezi životem a smrtí
C nemá garance
Go možná nějaké garance by se tam našli, ať mu nekřivdím, a má GC...
Julia a spol jsou jazyky (prej) spíše na vědecké výpočty. Netuším, zda se dá použít jako obecný jazyk. Natož nízkoúrovňový.

Hoď sem něco.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 11. 2022, 16:34:43
Haskel je pomalej
Určitě?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 11. 2022, 16:41:18
Julia a spol jsou jazyky (prej) spíše na vědecké výpočty. Netuším, zda se dá použít jako obecný jazyk.
Short answer: Dá.

Long answer: Dá, ale s praktickými omezeními. Julia sice generuje rychlý kód (zhruba na úrovni Rustu), ale těžko se cpe do kontejnerů. Takže se používá na vědeckých superclusterech, kdy nikoho velikost sysimage nezajímá, ale v běžné cloudové aplikace by to působilo nepatřičně (a oproti Go nebo Rustu, které jdou přeložit do malé statické binárky, nepřináší žádnou zásadní výhodu).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 06. 11. 2022, 16:41:52
Hoď sem něco.

A co bych sem měl házet? D má garance viz https://dlang.org/spec/memory-safe-d.html
https://dlang.org/blog/
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 06. 11. 2022, 16:45:05
Taky. Ale i to, že vývojáři Rustu vědí, že popularita záleží mimo jiné i na toolingu a lidech. Má D něco jako Cargo? Něco jako Rustup? A pokud ano, tak jak dlouho? Má třeba něco jako https://wiki.mozilla.org/Areweyet ? Jaké jsou referenční FOSS projekty v D? Co jsem našel a stálo za řeč, byly 5-8 let mrjvé repozitáře.

Hledáš takto špatně schválně?
https://code.dlang.org/
https://dlang.org/orgs-using-d.html
https://www.youtube.com/c/TheDLanguageFoundation/playlists
K tématu: https://dconf.org/2020/online/index.html#walter

Python a Rust opravdu nejsou jedinné použitelné jazyky ve svoji doméně. Mně osobně čím dál tím leze na nervy jejich evangelizace.


O co se D znažilo byla nějaká kompatibilita a konzumace C++ projektů... tam si Rust prostě ulevil. Dle názoru jiných to stálo D týmu dost energie a je to velké sousto. Podobně se o to snaží Google se svým Carbonem.

Proč schválně špatně? Že jsem si já osobně oblíbil Python a Rust nebylo tím, že bych si strčil prst do seznamu a pak si slíbil, že jim budu navždy věrný. Je to tím, že mě Perl, Ruby, OCaml, D, Common Lisp a další prostě nepřesvědčily, ač jsem jim dal šanci. Proč bych se bránil dát jim šanci?

A teď zpátky k "hledání". Víš co? Když budu chtít začít používat Rust, vezmu si Rust Book a naučím se tam (skoro) všechno. Hned na začátku mám odkazy na rustup a Cargo. Co mám v tutoriálu D? Vyber si z DMD, GDC a LDC! To je přece na hlavu! (Jo a Leave a Tip). Ale OK, nakonec pochopím, že mám asi použít DMD a dokonce tam je nějaký odkaz na dub. No ale uznej, že ta dokumentace je brutálně roztříštěná a srovnej to s Rust Bookem a jeho popisem práce s Cargem (a ne, Cargo nepoužívá 2 formáty pro popis balíčků, ale všechno má hezky v TOML).

Orgs using D mě fakt moc nezajímají (tam se používá klidně Haskell nebo Ada, to nepopírám), ptal jsem se na FOSS, ale OK - z těch známých, které mají nějaké repozitáře veřejně je to eBay (1 projekt v D ze 177 repozitářů), FB má 8 let starý Warp,  zbytek vesměs neznám nebo nemají nic veřejně k dispozici.

No a jestliže se D snažilo o to, co teď zkouší Google s Carbonem (nehledě tedy na to, že už zainvestoval do Go a hraje si i s Rustem), není to důkaz, že D pro Google není cesta?

Hele, chápu, že se Ti D líbí a chápu, že Tě evangelismus kolem Rustu a Pythonu štve. No ale obávám se, že to nebude mít žádný vliv na prosazení jednotlivých programovacích jazyků.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 06. 11. 2022, 17:10:43
Taky. Ale i to, že vývojáři Rustu vědí, že popularita záleží mimo jiné i na toolingu a lidech. Má D něco jako Cargo? Něco jako Rustup? A pokud ano, tak jak dlouho? Má třeba něco jako https://wiki.mozilla.org/Areweyet ? Jaké jsou referenční FOSS projekty v D? Co jsem našel a stálo za řeč, byly 5-8 let mrjvé repozitáře.

Hledáš takto špatně schválně?
https://code.dlang.org/
https://dlang.org/orgs-using-d.html
https://www.youtube.com/c/TheDLanguageFoundation/playlists
K tématu: https://dconf.org/2020/online/index.html#walter

Python a Rust opravdu nejsou jedinné použitelné jazyky ve svoji doméně. Mně osobně čím dál tím leze na nervy jejich evangelizace.


O co se D znažilo byla nějaká kompatibilita a konzumace C++ projektů... tam si Rust prostě ulevil. Dle názoru jiných to stálo D týmu dost energie a je to velké sousto. Podobně se o to snaží Google se svým Carbonem.

Proč schválně špatně? Že jsem si já osobně oblíbil Python a Rust nebylo tím, že bych si strčil prst do seznamu a pak si slíbil, že jim budu navždy věrný. Je to tím, že mě Perl, Ruby, OCaml, D, Common Lisp a další prostě nepřesvědčily, ač jsem jim dal šanci. Proč bych se bránil dát jim šanci?

A teď zpátky k "hledání". Víš co? Když budu chtít začít používat Rust, vezmu si Rust Book a naučím se tam (skoro) všechno. Hned na začátku mám odkazy na rustup a Cargo. Co mám v tutoriálu D? Vyber si z DMD, GDC a LDC! To je přece na hlavu! (Jo a Leave a Tip). Ale OK, nakonec pochopím, že mám asi použít DMD a dokonce tam je nějaký odkaz na dub. No ale uznej, že ta dokumentace je brutálně roztříštěná a srovnej to s Rust Bookem a jeho popisem práce s Cargem (a ne, Cargo nepoužívá 2 formáty pro popis balíčků, ale všechno má hezky v TOML).

Orgs using D mě fakt moc nezajímají (tam se používá klidně Haskell nebo Ada, to nepopírám), ptal jsem se na FOSS, ale OK - z těch známých, které mají nějaké repozitáře veřejně je to eBay (1 projekt v D ze 177 repozitářů), FB má 8 let starý Warp,  zbytek vesměs neznám nebo nemají nic veřejně k dispozici.

No a jestliže se D snažilo o to, co teď zkouší Google s Carbonem (nehledě tedy na to, že už zainvestoval do Go a hraje si i s Rustem), není to důkaz, že D pro Google není cesta?

Hele, chápu, že se Ti D líbí a chápu, že Tě evangelismus kolem Rustu a Pythonu štve. No ale obávám se, že to nebude mít žádný vliv na prosazení jednotlivých programovacích jazyků.

Nejsi trochu emotivní? D skoro nepoužívám, ale tvrdit že nedává garance je lež. Rust mě zajímá, jako každý jiný jazyk i když prakticky mě za to neplatí, takže investovat do něj nehodlám. Jazyky co mě opravdu zajímají jsou APL, Joy, Factor z těch co mám teď na stole. Python mě bohužel hodně zaměstnává a čím víc lidí do něj naskakuje, tím děsivější to je.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 11. 2022, 17:13:55
Hoď sem něco.

A co bych sem měl házet? D má garance viz https://dlang.org/spec/memory-safe-d.html
https://dlang.org/blog/
Hezký. Toto ale není to samé co garantuje Rust.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 11. 2022, 17:14:56
Haskel je pomalej
Určitě?
Ruku do ohně bych za to nedal. Máš nějakou zkušenost?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 11. 2022, 17:38:37
Haskel je pomalej
Určitě?
Ruku do ohně bych za to nedal. Máš nějakou zkušenost?
Jo, s Haskellem a Chezem, ty opravdu nejsou pomalejší než třeba C++. Dnes už neplatí staré “pravdy”, že funkcionální nebo dynamicky typované jazyky (Julia) jsou pomalejší než C++/Rust/Go…
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 06. 11. 2022, 18:59:55
Nejsi trochu emotivní? D skoro nepoužívám, ale tvrdit že nedává garance je lež. Rust mě zajímá, jako každý jiný jazyk i když prakticky mě za to neplatí, takže investovat do něj nehodlám. Jazyky co mě opravdu zajímají jsou APL, Joy, Factor z těch co mám teď na stole. Python mě bohužel hodně zaměstnává a čím víc lidí do něj naskakuje, tím děsivější to je.

Nejsem trochu emotivní. A o žádných garancích nic nepíšu. Jenom tvrdím, že lidi nabízející D jsou nepraktičtí a proto mi nepřijde, že ten jazyk má šanci šířeji prorazit. Klidně tomu říkej špatný marketing, to je nakonec jedno. Koneckonců, klasický marketingový mix je výrobek, cena, místo a propagace (product, price, place, promotion). Něco z toho neumějí, D se neprosadilo. EOF
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 11. 2022, 23:42:29
Haskel je pomalej
Určitě?
Ruku do ohně bych za to nedal. Máš nějakou zkušenost?
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í).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ondrej Nemecek 07. 11. 2022, 09:25:21
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 11. 2022, 09:43:33
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.
Sémanticky jsou immutable, ale kdyz překladač usoudí, že destruktivní změna není na škodu, provede ji, pokud to je efektivnější.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ondrej Nemecek 07. 11. 2022, 11:02:07
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.
Sémanticky jsou immutable, ale kdyz překladač usoudí, že destruktivní změna není na škodu, provede ji, pokud to je efektivnější.
Hmm, zajímavé, díky za info.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 11. 2022, 11:37:29
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 11. 2022, 12:00:45
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 11. 2022, 12:25:11
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 1). 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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Martin Sivák 07. 11. 2022, 12:25:36
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 11. 2022, 13:29:00
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č.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Martin Sivák 07. 11. 2022, 16:16:17
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 11. 2022, 17:19:09
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 :D
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 11. 2022, 18:07:34
ž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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 08. 11. 2022, 09:25:24
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ší.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 08. 11. 2022, 10:38:07
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 :D
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 08. 11. 2022, 10:40:17
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 08. 11. 2022, 21:32:16
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 08. 11. 2022, 22:57:35
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 08. 11. 2022, 23:26:18
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 08. 11. 2022, 23:30:00
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: APhacker_mob 08. 11. 2022, 23:43:30
Okolo Haskellu existuje neco jako LARP kultura. Predstira se, ze vse je v Haskellu teoreticky mozne, ale v praxi to realizovat, ukazat jak, je pod uroven Haskellovske komunity intelektualu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 08. 11. 2022, 23:50:15
U některých jazyků vím, že objekt/struct/whatever jsou fieldy poskládané v paměti za sebe,
To potřebuješ vědět?
Lua to třeba nemá. Ačkoliv, dynamický jazyk bychom mohli považovat za trošku vysokoúrovňový.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 09. 11. 2022, 00:36:34
Většinou to vědět nepotřebuju, ale někdy se to hodí. Třeba když řeším paměťovou náročnost. Extrémní příklad může být s rastrovým obrázkem. Nejpřirozeněji bych ho vyjádřil jako dvojrozměrné pole objektů typu třeba RGB. (Vím, RGB není jediná možnost, ale dejme tomu, že nám to bude stačit ) První problém je dvourozměrné pole – spousta jazyků místo toho nabídne pole polí, které je mocnější, ale méně efektivní. Druhý problém je v některých jazycích ten objekt typu RGB. Já bych potřeboval dejme tomu 3 byty na objekt (záleží na barevné hloubce, ale nekomplikujme to). V Javě se k tomu přidává už celkem slušný overhead – už jenom reference na ten objekt zabere víc, nemluvě o tom, že objekt potřebuje hlavičku jednak kvůli popisu třídy (VMT apod.) a jednak kvůli zamykání (každý objekt je i zámek). Z hlavy nereknu, kolik přesně obrázek zabere, ale zjevně to bude několikanásobně vícz než je účelné. A v Pythonu to bude ještě horší, každý objekt je i dictionary…

Mimochodem, podobné případy přinášejí zajímavý paradox – ve vyšším jazyce bych pravděpodobně použil víc low-level přístup (jako obrovské pole bytů), abych se vyhnul tomu overheadu. V low-level jazyce s vhodnou abstrakcí to není tolik potřeba
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 09. 11. 2022, 04:05:00
Většinou to vědět nepotřebuju, ale někdy se to hodí. Třeba když řeším paměťovou náročnost. Extrémní příklad může být s rastrovým obrázkem. Nejpřirozeněji bych ho vyjádřil jako dvojrozměrné pole objektů typu třeba RGB. (Vím, RGB není jediná možnost, ale dejme tomu, že nám to bude stačit ) První problém je dvourozměrné pole – spousta jazyků místo toho nabídne pole polí, které je mocnější, ale méně efektivní. Druhý problém je v některých jazycích ten objekt typu RGB. Já bych potřeboval dejme tomu 3 byty na objekt (záleží na barevné hloubce, ale nekomplikujme to). V Javě se k tomu přidává už celkem slušný overhead – už jenom reference na ten objekt zabere víc, nemluvě o tom, že objekt potřebuje hlavičku jednak kvůli popisu třídy (VMT apod.) a jednak kvůli zamykání (každý objekt je i zámek). Z hlavy nereknu, kolik přesně obrázek zabere, ale zjevně to bude několikanásobně vícz než je účelné. A v Pythonu to bude ještě horší, každý objekt je i dictionary…

Mimochodem, podobné případy přinášejí zajímavý paradox – ve vyšším jazyce bych pravděpodobně použil víc low-level přístup (jako obrovské pole bytů), abych se vyhnul tomu overheadu. V low-level jazyce s vhodnou abstrakcí to není tolik potřeba

Já bych teda intuitivně udělal RGB jako typ, a dvourozměrné pole (jak popisuješ), parser a serializer. A pak bych očekával, že ten Haskell si tu paměťovou náročnost odvodí a zoptimalizuje sám.

Ve skutečnosti vůbec netuším jak by to dopadlo. Třeba by zklamal, třeba ne. Jakou ale mám zkušenost z "vysokoúrovňových" jazyků, tak snažit se jim pomáhat s nějakou paměťovou (nebo jinou) náročností je a/ principielně chyba; b/ v praxi ale někdy třeba.

Smyslem vysokoúrovňových jazyků je, že to dokáží udělat místo tebe a lépe, a ty jim jen řekneš co chceš. Jakmile jim místo zadání začneš pomáhat s implementací, většinou je zmateš - ale tady se začínám pohybovat v tekutých píscích teorie a ideí.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: redustin 09. 11. 2022, 09:01:53
Spoustu teorie, ale moc jsem tu nenašel praktické zkušenosti.

Mně Rust vyhovuje, protože lze s minimálním úsilím vyvíjet multiplatformní řešení. Instalace kompilačního prostředí je o stažení jedné binárky z netu (rustup) a jejím spuštění, na všech podporovaných platformách. Aktualizace na novou verzi rustu - opět jeden příkaz. Výsledné binárky jsou velice svižné, nemají problémy s latencí (bez GC), velice snadno přenositelné mezi platformami. Debug je plný užitečných kontrol, po vychytání problémů stačí přidat "--release" a mám několikanásobně menší binárku plnou optimalizací, která běží výkonově i paměťově úsporně, srovnatelně s Cečkem.

Vývoj je velice pohodlný a úplně stejný ve win i v linuxu - stáhnout Intellij Community version a dokliknout Rust plugin. Plugin se drží aktuálního vývoje jazyka, nová verze každých pár dnů. Idea/plugin vše naindexuje, prokliky metod externích crates vedou rovnou do jejich zdrojáků. Zobrazování chyb rovnou při psaní je zrovna v Rustu hodně užitečné, obzvláště pro poučeného začátečníka jako já.  Vývoj je nesrovnatelně rychlejší, než čekat, až s čím přijde kompilátor. Sice v community verzi nefungují v rustu breakpointy, ale to není tak velká překážka.

Snadno mohu zdrojáky crate naklonovat do vedlejšího adresáře a upravovat ji současně s mím projektem v jednom prostředí, pokud něco v nich potřebuji upravit, atd. Vyleze mi opět jedna binárka, a pokud autor crate akceptuje mé změny (typicky zveřejnění užitečných fieldů v public struktech) a vydá novou verzi, stačí v cargo.toml přehodit dependency změnit  jeden řádek na novou upstream verzi. V kompilaci nemusím měnit nic, vše se děje automaticky na pozadí.

Pro SBC/ARM si vyvinu/zkompiluji pohodlně v IDE na mnohojádrové pracovní stanici s několika velkými monitory, cross-zkompiluji do arm64 a stačí přes scp překopírovat binárku na RPi, která by se jinak při kompilaci pořádně zapotila a já předopoval kafem.

Narozdíl od C mám k dispozici pohodlnou paletu hotových struktur, pohodlí téměř jako v javě (hashmapy, hashsety, kanály mezi vlákny všech možných vlastností), dobře vyřešenou podporu chyb s minimální režií, pořádné enumy.

Kompilátor mě nutí psát přehlednější kód. Když srovnám první verzi a verzi po delším boji akceptovanou kompilátorem, snad vždycky je výsledek čistější, logičtější, méně zašmodrchaný, se správně vyřešeným vlastnictvím, atd. Obvykle si po vyřešení konkrétní stížnosti kompilátoru říkám - no jo, takhle to dává smysl, proč jsem to tak neudělal rovnou... Jsou i výjimky, kdy je zkompilovatelný kód více "přes ruku", ale s každou verzi rustu jich ubývá.

Programy napsané v rustu bych v C nikdy nenapsal, protože bych neuměl tak pečlivě hlídat paměť a hodně dlouho bych lovil segfaulty. V Rustu to po první úspěšné kompilaci funguje na 90%, i složitější programy s více vlákny.

Ve win jsem nikdy neprogramoval a s rustem jsem si troufl na javasound nativní DLL pro WASAPI Exclusive https://github.com/pavhofman/csjsound-wasapi . Je tam samozřejmě SPOUSTU prostoru ke zlepšování, ale bez rustu bych na windowsí DLL ani nepomyslel, v C/C++ jsem systémové věci ve windowsech nikdy nedělal, nevím ani v čem bych ten kód psal.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 09. 11. 2022, 09:10:33
S ideou, že ve vyšším jazyku řeknu, co chci, a kompilátor to vymyslí co nejlépe, v zásadě souhlasím. A slyšel jsem nějaké anekdotické případy, kdy například GCC vyhrál nad ručně optimalizovaným assembly code, protože vývojáři kompilátoru byli zkušenější. Kompilátory (obzvlášť JIT) někdy dovedou zajímavé věci. Třeba OpenJDK a GraalVM dovedou z dynamické alokace udělat alokaci na stacku, pokud si odvodí, že proměnná má odpovídající životnost. Obávám se ale, že s podobným typem byste v Haskellu krutě pohořel. Rád bych viděl ten kompilátor, co něco takového dovede dobře zanalyzovat a optimalizovat. I pokud byste použil typ pro dvourozměrné pole (má Haskell něco takového?), potřeboval by kompilátor pár věcí, ke kterým jsem skeptický. Je tu pár úkolů, které by si vyžádaly hlubokou analýzu celého programu:

1. Zjistit, že je výhodnější striktní vyhodnocování. To není vůbec snadné. Co když uděláte nějakou náročnou operaci, ale nakonec z obrázku budete chtít jen malý výřez?
2. Vyřešit případné time/space tradeoffs. OK, možná striktní vyhodnocování sníží paměťovou náročnost, ale zvýší časovou náročnost. Co pak preferujeme?
3. Ujistit se, že striktní vyhodnocování je korektní, případně udělat plán B. Haskell má sémantiku líného vyhodnocování. Z hlediska chování to znamená, že mohu mít obrázek s vadným subpixelem (například v jeho výpočtu dělím nulou nebo nekonečný výpočet*), chyba se projeví, až ho budu číst a hlavně jenom pokud ho budu číst. To rozhodně není snadné analyzovat. Pokud si s tím kompilátor nemůže být jistý, potřebuje mít plán B (překopat datové struktury za běhu), což není sranda, a může to znamenat v podstatě náhlý zásek.
4. Následně se rozhodnout, že místo ukazatele na RGB bude výhodnější přímo samotná hodnota. To by teoreticky mohl kompilátor rozhodnout snadno, pokud ví o neměnnosti (v Haskellu OK), používá striktní vyhodnocování (vizte body výše) a může tam být jen jediný typ (žádná dědičnost, v Haskellu asi OK). Problém by trochu nastal v případě onoho plánu B, protože pak by musel překopat nikoli jeden pixel, ale rovnou celý obrázek.

Pokud byste nepoužil dvourozměrné pole, ale přímočaře [[RGB]], bylo by to pro kompilátor ještě složitější:

1. Ze samotného typu nevyplývá, že jde o obdélníkový obrázek. Ve skutečnosti může jít o obdélník s různě ustřiženým jedním (typicky pravým; záleží na interpretaci dat) okrajem, protože vnitřní seznamy mohou být různě dlouhé.
2. List je v Haskellu spojový seznam, se vším, co z toho plyne pro paměťovou náročnost a výkon. To není jen nějaký implementační detail. To Haskell vystavuje tím, že jednak můžete seznam rozdělit na head a tail, a jednak můžete k seznamu přidat nový head, a přitom zachovat původní seznam. Ano, teoreticky by se kompilátor mohl rozhodnout použít pole, čímž některé operace zlevní a jiné zdraží (jak z hlediska času, tak z hlediska paměti), ale opět není sranda toto analyzovat. To bych se ale opakoval.

BTW, nevím, k čemu by Haskellu byl parser a serializer. Typ RGB je v podstatě struktura tří 1B integerů, k tomu lze serializaci a deserializaci vygenerovat snadno automaticky.

*) Nabízí se tu argumentovat problémem zastavení. Jeho neřešitelnost nám nicméně neříká, že to nedovedeme vyřešit nikdy. Můžeme mít algoritmus, který bude říkat ano/ne/nevím, přičemž v tom „nevím“ budou jak případy, které se zastaví, tak případy, které se nezastaví. Každopádně pokud u aspoň jednoho výpočtu pixelu nevíme, kompilátor potřebuje onen plán B.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vietnamka 09. 11. 2022, 12:40:26
why-discord-is-switching-from-go-to-rust[/url]

Já myslel, že discord byl postaveý a Erlangu? Nebo to nelo ještě dřív nebo jiná sociální/messaging síť?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 09. 11. 2022, 13:04:41
nevím, k čemu by Haskellu byl parser a serializer.
Protože ten je podstatný. Je to vstup a výstup pro ten typ. Takže cokoliv mezi tím může Haskell 1) optimalizovat. Pokud ho definuješ, rozvážeš mu ruce a pak už ho nějaký lazy vyhodnocování vůbec nezajímá.

To co popisuješ a jak argumentuješ je charakteristické pro JITované jazyky jako je Java a ve skutečnosti i C, kde kompilátor tomu kódu moc nerozumí. V Javě pak za běhu odvozuje charekter dat. V Haskellu má mnohem víc informací, a mnohem méně omezení.

sníží paměťovou náročnost, ale zvýší časovou náročnost. Co pak preferujeme?
Tady jsem trochu zaváhal. Netuším, zda to lze nějak ovlivňovat. V praxi se skutečně v tomto případě používá porušování toho principu "nenavádět", a začne se do toho Haskellu kecat pomocí strict a unsafe. Jestli na to jiné nástroje mají nějaké lepší instrumenty už žel netuším.


1/ Čímž netvrdím, že to dělá; vůbec netvrdím, že se to tak skutečně provede. Ale vzhledem k tomu, jaké brutální optimalizace dokáže GCC s hloupoučkým C, tak proč by to Haskell nedal ještě líp.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 09. 11. 2022, 13:51:49
Kompilátory (obzvlášť JIT) někdy dovedou zajímavé věci. Třeba OpenJDK a GraalVM dovedou z dynamické alokace udělat alokaci na stacku, pokud si odvodí, že proměnná má odpovídající životnost.
Tohle se ve FP řeší na úrovni typového systému přes multiplicitu (nebo lineární typy). Má to tak prastaré Mercury nebo třeba Idris (to je skoro Haskell).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: user398 09. 11. 2022, 14:37:44
Já myslel, že discord byl postaveý a Erlangu? Nebo to nelo ještě dřív nebo jiná sociální/messaging síť?
Erlang pouziva WhatsApp.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: _Tomáš_ 09. 11. 2022, 15:20:35
Já myslel, že discord byl postaveý a Erlangu? Nebo to nelo ještě dřív nebo jiná sociální/messaging síť?
Erlang pouziva WhatsApp.

Poté co ho FB koupil byl přemigrovaný ja jejich platformu, to už je tak 3, 4 roky zpátky.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: APhacker_mob 09. 11. 2022, 17:43:18
Velka cast algoritmu je z podstaty in-place. Logicky je nelze implementovat ciste funkcionalne.

Haskell vychazi z moderni "matematiky", ktera neresi zadny realny problem, jen vytvari teorie pro teorie.

"Modern Mathematics' and by similar soft intellectual trash in schools and universities"

https://archive.org/details/hammersley1968

Cil zidovske "vedy" obecne neni poznani nebo reseni praktickych problemu
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 09. 11. 2022, 21:08:00
nevím, k čemu by Haskellu byl parser a serializer.
Protože ten je podstatný. Je to vstup a výstup pro ten typ. Takže cokoliv mezi tím může Haskell 1) optimalizovat. Pokud ho definuješ, rozvážeš mu ruce a pak už ho nějaký lazy vyhodnocování vůbec nezajímá.

Možná to bude moje neznalost Haskellu, ale pořád mi to nedává smysl. Pokud by to mělo mít nějaký sémantický význam, ze kterého lze tu optimalizaci odvodit, mohl by to být jen nějaký příznak, a kompilátor si může parser a serializer vygenerovat u takto jednoduché struktury sám.

To co popisuješ a jak argumentuješ je charakteristické pro JITované jazyky jako je Java a ve skutečnosti i C, kde kompilátor tomu kódu moc nerozumí. V Javě pak za běhu odvozuje charekter dat. V Haskellu má mnohem víc informací, a mnohem méně omezení.

No věřím, že v Haskellu má kompilátor některé věci jednodušší. Ale jsem dost skeptický, že bez dalšího zvládne udělat ten rastr efektivně, z důvodů, které jsem psal.

sníží paměťovou náročnost, ale zvýší časovou náročnost. Co pak preferujeme?
Tady jsem trochu zaváhal. Netuším, zda to lze nějak ovlivňovat. V praxi se skutečně v tomto případě používá porušování toho principu "nenavádět", a začne se do toho Haskellu kecat pomocí strict a unsafe. Jestli na to jiné nástroje mají nějaké lepší instrumenty už žel netuším.

Věřím, že s nějakým strict byste té optimalizace dosáhl. Jistý si s tím nejsem, ale věřil bych tomu.

1/ Čímž netvrdím, že to dělá; vůbec netvrdím, že se to tak skutečně provede. Ale vzhledem k tomu, jaké brutální optimalizace dokáže GCC s hloupoučkým C, tak proč by to Haskell nedal ještě líp.

Tím jsme u toho, proč jsem Haskell označil za extrémně vysokoúrovňový. Něco napíšete, a doufáte, že se s tím kompilátor dobře popere. Neříkám, že je tento přístup špatně, někdy se hodí nízkoúrovňovější přístup (např. řešíme side channels u kryptografie, tam optimalizace kompilátoru mohou i škodit…), někdy vysokoúrovňovější.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 09. 11. 2022, 21:13:23
Tím jsme u toho, proč jsem Haskell označil za extrémně vysokoúrovňový. Něco napíšete, a doufáte, že se s tím kompilátor dobře popere.
To je všude, ten překladač je v podstatě celkem jednoduchý. Čistě funkcionální kód v Rustu po přeložení vypadá stejně jako stejný kód v nějakém funkcionálním jazyce.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 09. 11. 2022, 21:52:13
V nějaké míře ano (ostatně některé úpravy dělají i moderní CPU, takže se tomu nevyhnete ani assemblerem…), ale liší se míra.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 09. 11. 2022, 21:59:08
nevím, k čemu by Haskellu byl parser a serializer.
Protože ten je podstatný. Je to vstup a výstup pro ten typ. Takže cokoliv mezi tím může Haskell 1) optimalizovat. Pokud ho definuješ, rozvážeš mu ruce a pak už ho nějaký lazy vyhodnocování vůbec nezajímá.

Možná to bude moje neznalost Haskellu, ale pořád mi to nedává smysl. Pokud by to mělo mít nějaký sémantický význam, ze kterého lze tu optimalizaci odvodit, mohl by to být jen nějaký příznak, a kompilátor si může parser a serializer vygenerovat u takto jednoduché struktury sám.
Já taky nejsem žádnej guru. Jde ale o to uvažování. (Snad nejsem moc mimo.)
Pokud v Haskellu vytvoříš strukturu (jakkoliv sofistikovanou) obrázku, provedeš na ní libovolné transformace, a ten zdrojový obrázek tam vložíš ručně jako literál, tak ti to Haskell s velkou pravděpodobností zoptimalizuje tak brutálně, že to bude třeba dvakrát rychlejší jak kdybys to napsal v assembleru. Hádej proč :-)

Když tam vytvoříš (a použiješ) parser a serializer tak se kouzlem změní pravidla hry, a Haskell bude muset optimalizovat jinak.


To co popisuješ a jak argumentuješ je charakteristické pro JITované jazyky jako je Java a ve skutečnosti i C, kde kompilátor tomu kódu moc nerozumí. V Javě pak za běhu odvozuje charekter dat. V Haskellu má mnohem víc informací, a mnohem méně omezení.

No věřím, že v Haskellu má kompilátor některé věci jednodušší. Ale jsem dost skeptický, že bez dalšího zvládne udělat ten rastr efektivně, z důvodů, které jsem psal.
Já se vážně obávám, že ty důvody jsou naprosto liché. Vychází z tvých bohatých zkušeností s GrallVM a JIT. Haskell nějaké laziness vůbec nezajímá, to zcela jistě problém nebude. Halt problém je věc trochu bokem. A jediné, co mě zaujalo byla skutečnost, že Haskell má nějaké defaultní nastavení zda preferovat rychlost či paměťovou náročnost. Což by bylo správně (tm) řešit nějakým klíčovým slovem nebo podobnou formou jazyka. Ale to opravdu neznám jestli někde v nějakém jazyce je chytře deklarativně řešeno.


Věřím, že s nějakým strict byste té optimalizace dosáhl. Jistý si s tím nejsem, ale věřil bych tomu.
Tohle se normálně v praxi používá. Ale je to ideově špatné :-) Takhle by se to dělat nemělo, i když to funguje.


Tím jsme u toho, proč jsem Haskell označil za extrémně vysokoúrovňový. Něco napíšete, a doufáte, že se s tím kompilátor dobře popere. Neříkám, že je tento přístup špatně, někdy se hodí nízkoúrovňovější přístup (např. řešíme side channels u kryptografie, tam optimalizace kompilátoru mohou i škodit…), někdy vysokoúrovňovější.
Jo, Haskell je vysokoúrovňový. A ve svých snech si představuju, že by to mohlo jít ještě extréměji. A někdo to chce, někdo ne. Věřím, že mi vyhrajem. :-)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 09. 11. 2022, 22:37:52
Pokud v Haskellu vytvoříš strukturu (jakkoliv sofistikovanou) obrázku, provedeš na ní libovolné transformace, a ten zdrojový obrázek tam vložíš ručně jako literál, tak ti to Haskell s velkou pravděpodobností zoptimalizuje tak brutálně, že to bude třeba dvakrát rychlejší jak kdybys to napsal v assembleru. Hádej proč :-)
Tak zrovna tady je to jen o tom, že něco lze spočítat již v době kompilace. V takovémto případě může kompilátor rovnou do binárky hodit výsledek…

Když tam vytvoříš (a použiješ) parser a serializer tak se kouzlem změní pravidla hry, a Haskell bude muset optimalizovat jinak.
Sorry, já to tam stále nevidím. Jsou to věci, které by si v nějaké podobě mohl kompilátor vygenerovat sám (a asi je jedno, v jakém pořadí se serializují jednotlivé složky barvy), pokud mu to pomůže. Takže moc nevidím, v čem pomůže, když to napíšu ručně.

Já se vážně obávám, že ty důvody jsou naprosto liché. Vychází z tvých bohatých zkušeností s GrallVM a JIT. Haskell nějaké laziness vůbec nezajímá, to zcela jistě problém nebude.
Haskell je lazy už v sémantice, takže to musí kompilátor zajímat…

Věřím, že s nějakým strict byste té optimalizace dosáhl. Jistý si s tím nejsem, ale věřil bych tomu.
Tohle se normálně v praxi používá. Ale je to ideově špatné :-) Takhle by se to dělat nemělo, i když to funguje.
Holt na konci dne je potřeba nějak splnit požadavky uživatelů, i když to někdy vyžaduje něco, čemu bychom se radši vyhnuli…

Jo, Haskell je vysokoúrovňový. A ve svých snech si představuju, že by to mohlo jít ještě extréměji. A někdo to chce, někdo ne. Věřím, že mi vyhrajem. :-)
Asi by to mohlo jít i extrémněji, a asi to bude v nějakých situacích přínosem. Obecně to ale IMHO není otázka toho, co vyhraje, ale co se hodí ve které situaci…
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 09. 11. 2022, 23:04:14
Pokud v Haskellu vytvoříš strukturu (jakkoliv sofistikovanou) obrázku, provedeš na ní libovolné transformace, a ten zdrojový obrázek tam vložíš ručně jako literál, tak ti to Haskell s velkou pravděpodobností zoptimalizuje tak brutálně, že to bude třeba dvakrát rychlejší jak kdybys to napsal v assembleru. Hádej proč :-)
Tak zrovna tady je to jen o tom, že něco lze spočítat již v době kompilace. V takovémto případě může kompilátor rovnou do binárky hodit výsledek…
Tak. A o tom to je.


Když tam vytvoříš (a použiješ) parser a serializer tak se kouzlem změní pravidla hry, a Haskell bude muset optimalizovat jinak.
Sorry, já to tam stále nevidím. Jsou to věci, které by si v nějaké podobě mohl kompilátor vygenerovat sám (a asi je jedno, v jakém pořadí se serializují jednotlivé složky barvy), pokud mu to pomůže. Takže moc nevidím, v čem pomůže, když to napíšu ručně.
Nejde o to, že si ho musíš napsat ručně. To jsem se špatně vyjádřil. Jde o to, že ho musíš definovat. Tím, že použiješ serializátor (i kdyby automatický, ale prostě ho máš a použiješ), tak tím zabráníš kompilátoru v možnosti celej obrázek zahodit. Když použiješ parser, tak kompilátor najednou neví jak přesně ty hodnoty budou vypadat a nemůže to rovnou hodit do binárky. Věřím, že to je ti jasné.

Hlavně, počítá se začátek a konec. To mezi tím je nedůležité (nadsázka).

A já jsem se hlavně chytil toho tvého popisu uvažování. Když si vytvoříš strukturu trojice barev, a tu dáš do dvou rozměrného pole, tak ty tím Haskellu (nebo libovolnému jinému jazyku) neříkáš, že skutečně musí vytvořit strukturu tak jak jsi ji popsal. Vůbec ne. On si to klidně může přeložit jako proud bytů [červerná zelená modrá červená zelená modrá ...]. Nebo může udělat tři separátní proudy. Nebo ještě jinak. Nemusí tam být jedinej ukazatel. Prostě nemusí. Proč by měl?

Stejně jako když funkcionální jazyk má všechno immutable, tak to přeci taky neznamená, že v:
Kód: [Vybrat]
let xs = [1 .. 256]
let xs1 = filter f1 xs
let xs2 = map f2 xs1
budou tři 256prvkové pole.

v čem pomůže, když to napíšu ručně.
Ty mu řekneš, že na vstupu a výstupu je pořadí barev je RGB. To on neví, to mu musíš určit. Ale mezi tím si ty barvy pomíchá třeba na BGR. Nebo po klastrech.


Já se vážně obávám, že ty důvody jsou naprosto liché. Vychází z tvých bohatých zkušeností s GrallVM a JIT. Haskell nějaké laziness vůbec nezajímá, to zcela jistě problém nebude.
Haskell je lazy už v sémantice, takže to musí kompilátor zajímat…
Proč by mělo? Kompilátor samozřejmě rozumí tomu, že je to lazy, ale to přeci neznamená, že to lazy být musí. Jen se to tak musí jakože chovat navenek. To je to samé jako s tou immutabilitou. Samozřejmě, že kompilátor brutálně přepisuje tu samou paměť.


Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 09. 11. 2022, 23:26:40
Nejde o to, že si ho musíš napsat ručně. To jsem se špatně vyjádřil. Jde o to, že ho musíš definovat. Tím, že použiješ serializátor (i kdyby automatický, ale prostě ho máš a použiješ), tak tím zabráníš kompilátoru v možnosti celej obrázek zahodit. Když použiješ parser, tak kompilátor najednou neví jak přesně ty hodnoty budou vypadat a nemůže to rovnou hodit do binárky. Věřím, že to je ti jasné.

Aha, takže IIUC jde o klasický trik, který se používá u benchmarků, aby kompilátor „nepodváděl". Výslednou hodnotu pošle někam do /dev/null, ale poslat ji musí, aby nešidil. Ale potom to není jen o nadefinování parseru/serializéru, ale i o jejich použití.


A já jsem se hlavně chytil toho tvého popisu uvažování. Když si vytvoříš strukturu trojice barev, a tu dáš do dvou rozměrného pole, tak ty tím Haskellu (nebo libovolnému jinému jazyku) neříkáš, že skutečně musí vytvořit strukturu tak jak jsi ji popsal. Vůbec ne. On si to klidně může přeložit jako proud bytů [červerná zelená modrá červená zelená modrá ...]. Nebo může udělat tři separátní proudy. Nebo ještě jinak. Nemusí tam být jedinej ukazatel. Prostě nemusí. Proč by měl?
S tím libovolným jiným jazykem to je asi trochu silné tvrzení, ale v případě Haskellu to asi platí.


Stejně jako když funkcionální jazyk má všechno immutable, tak to přeci taky neznamená, že v:
Kód: [Vybrat]
let xs = [1 .. 256]
let xs1 = filter f1 xs
let xs2 = map f2 xs1
budou tři 256prvkové pole.
To ne, zejména v Haskellu, který je líný.


Proč by mělo? Kompilátor samozřejmě rozumí tomu, že je to lazy, ale to přeci neznamená, že to lazy být musí. Jen se to tak musí jakože chovat navenek. To je to samé jako s tou immutabilitou. Samozřejmě, že kompilátor brutálně přepisuje tu samou paměť.
V případě laziness má kompilátor teoreticky celkem volné ruce, prakticky to není tak snadné. Aby to bylo korektní, musí se poprat se situacemi, kdy a. výpočet skončí chybou a b. výpočet neskončí nikdy, nebo by trval extrémně dlouho. V praxi to v kombinaci s neřešitelností problému zastavení bude znamenat, že budou existovat situace, kdy by šlo použít striktní vyhodnocení, ale kompilátor to nezjistí.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 10. 11. 2022, 00:42:37
Nejde o to, že si ho musíš napsat ručně. To jsem se špatně vyjádřil. Jde o to, že ho musíš definovat. Tím, že použiješ serializátor (i kdyby automatický, ale prostě ho máš a použiješ), tak tím zabráníš kompilátoru v možnosti celej obrázek zahodit. Když použiješ parser, tak kompilátor najednou neví jak přesně ty hodnoty budou vypadat a nemůže to rovnou hodit do binárky. Věřím, že to je ti jasné.

Aha, takže IIUC jde o klasický trik, který se používá u benchmarků, aby kompilátor „nepodváděl". Výslednou hodnotu pošle někam do /dev/null, ale poslat ji musí, aby nešidil. Ale potom to není jen o nadefinování parseru/serializéru, ale i o jejich použití.
Ano. Zvolil jsem špatné slovo a zmátl tě.


A já jsem se hlavně chytil toho tvého popisu uvažování. Když si vytvoříš strukturu trojice barev, a tu dáš do dvou rozměrného pole, tak ty tím Haskellu (nebo libovolnému jinému jazyku) neříkáš, že skutečně musí vytvořit strukturu tak jak jsi ji popsal. Vůbec ne. On si to klidně může přeložit jako proud bytů [červerná zelená modrá červená zelená modrá ...]. Nebo může udělat tři separátní proudy. Nebo ještě jinak. Nemusí tam být jedinej ukazatel. Prostě nemusí. Proč by měl?
S tím libovolným jiným jazykem to je asi trochu silné tvrzení, ale v případě Haskellu to asi platí.
Tak tím libovolným nemyslím doslova libovolným, ale asi by to nemělo mít nějaké zvláštní omezení.


Stejně jako když funkcionální jazyk má všechno immutable, tak to přeci taky neznamená, že v:
Kód: [Vybrat]
let xs = [1 .. 256]
let xs1 = filter f1 xs
let xs2 = map f2 xs1
budou tři 256prvkové pole.
To ne, zejména v Haskellu, který je líný.
Kód: [Vybrat]
let xs = strictList [1 .. 256]
let xs1 = strictList $ filter f1 xs
let xs2 = strictList $ map f2 xs1
Lepší?



Proč by mělo? Kompilátor samozřejmě rozumí tomu, že je to lazy, ale to přeci neznamená, že to lazy být musí. Jen se to tak musí jakože chovat navenek. To je to samé jako s tou immutabilitou. Samozřejmě, že kompilátor brutálně přepisuje tu samou paměť.
V případě laziness má kompilátor teoreticky celkem volné ruce, prakticky to není tak snadné. Aby to bylo korektní, musí se poprat se situacemi, kdy a. výpočet skončí chybou a b. výpočet neskončí nikdy, nebo by trval extrémně dlouho. V praxi to v kombinaci s neřešitelností problému zastavení bude znamenat, že budou existovat situace, kdy by šlo použít striktní vyhodnocení, ale kompilátor to nezjistí.

Ano, to jistě. Určitě tam budou nějaké hranice. A snaha programovacích jazyků (k danému tématu o kterém sa bavím) je vytvořit paradigma, aby se do těchto situací nedostával (což lazyness zrovna není moc zásah do černého, asi, nevím) a přitom vývojář nemusel pomáhat. Protože když se vývojář snaží pomáhat, vždy škodí.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Rike 29. 11. 2022, 13:00:04
Dal by mi někdo tip na literaturu k Rustu nad rámec té jejich defaultní knihy, co mají na webu? Něco, co se víc zaměřuje na praktické využití, návrhové vzory a obvyklé postupy, hlubší pochopení lifetime a bude to relativně nové (aby to obsahovalo ty poslední změny, které se mi jeví totálně nečitelné)?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: JsemJenMetar 29. 11. 2022, 13:35:12
https://nostarch.com/rust-rustaceans
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Sam Samovic 30. 11. 2022, 11:21:28
Tak C nenahradí, C++ také ne, Javu asi také ne, Python a Javascript rovněž. Myslím že ne.

Jaký jazyk nahradila Java? (Což je jeden z nejúspěšnějších jazyků a očividně měla budoucnost.) Jaký jazyk nahradil Python?

Tak my lide jsme obecne dobri ve hre s nazvem "tristeni sil".  Tak tu mame 300neodladenych distribuci a nove jazyky vznikajici jak houby po desti. Psi stekaji a karavana jde dal.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 30. 11. 2022, 11:56:16
Tak my lide jsme obecne dobri ve hre s nazvem "tristeni sil".  Tak tu mame 300neodladenych distribuci a nove jazyky vznikajici jak houby po desti. Psi stekaji a karavana jde dal.
Specializované jazyky mohou mít smysl. Rust vznikl pro napsání jádra prohlížeče, jen se to pak nějak vymklo.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: oss 30. 11. 2022, 12:56:14
Tak my lide jsme obecne dobri ve hre s nazvem "tristeni sil".  Tak tu mame 300neodladenych distribuci a nove jazyky vznikajici jak houby po desti. Psi stekaji a karavana jde dal.
Specializované jazyky mohou mít smysl. Rust vznikl pro napsání jádra prohlížeče, jen se to pak nějak vymklo.

A vyzera to, ze nakoniec v nom to jadro prehladaca aj tak nebude.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: ondra05 30. 11. 2022, 17:07:53
Tak my lide jsme obecne dobri ve hre s nazvem "tristeni sil".  Tak tu mame 300neodladenych distribuci a nove jazyky vznikajici jak houby po desti. Psi stekaji a karavana jde dal.
Specializované jazyky mohou mít smysl. Rust vznikl pro napsání jádra prohlížeče, jen se to pak nějak vymklo.

Ale nevznikl, byl to původně osobní projekt Graydona Hoarea až to poté Mozilla začala rozvíjet pro Servo ale od začátku to byl jazyk na obecné použití.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 01. 12. 2022, 14:09:13
hloubkové pochopení typového systému a dalších aspektů Rustu přesahuje mentální obzor poměrně velké skupiny programátorů (nechme stranou debaty, jestli by se neměli raději živit něčím jiným).
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?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 01. 12. 2022, 14:24:23
hloubkové pochopení typového systému a dalších aspektů Rustu přesahuje mentální obzor poměrně velké skupiny programátorů (nechme stranou debaty, jestli by se neměli raději živit něčím jiným).
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?

Ty jsi dobrý necromancer. Ano, pomiň Agdu, Coq, Scalu, OCaml a Rust a začneš se blížit realitě "normálního" programátora.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Rike 01. 12. 2022, 14:29:36
https://nostarch.com/rust-rustaceans
Díky za tip, objednáno.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Petr Branik 01. 12. 2022, 14:30:01
Tyhle diskuse me vzdy bavi a pritom odpoved je jasna. Fortran a LISP.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 01. 12. 2022, 14:43:29
Ano, pomiň Agdu, Coq, Scalu, OCaml a Rust a začneš se blížit realitě "normálního" programátora.
Rust ne, ten nemá nijak sofistikovaný typový systém.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 01. 12. 2022, 14:43:54
Tyhle diskuse me vzdy bavi a pritom odpoved je jasna. Fortran a LISP.
  :o
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: echo_zulu 01. 12. 2022, 15:45:12
Tyhle diskuse me vzdy bavi a pritom odpoved je jasna. Fortran a LISP.

Ešte si dovolím doplniť editor: https://youtu.be/qzC5H5xrr-E?t=55

Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 01. 12. 2022, 18:19:47
Nevím, jak se ten “mentální obzor” měří

Používají "moderní" jazyky jako je C#.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 01. 12. 2022, 18:51:14
Nevím, jak se ten “mentální obzor” měří
Používají "moderní" jazyky jako je C#.
Aha.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 01. 12. 2022, 18:55:26
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).
Borrowing není součást typového systému, s typy vůbec nesouvisí. Java má například silnější typový systém (má navíc explicitní varianci typů), používá ji mnohem více vývojářů a o jejich “mentálním obzoru” si nedělám iluze.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: oss 02. 12. 2022, 07:12:39
V com ma haskell zlozity typovy system? Mne nepride nicim vynimocny ani zlozity ani tazky a to som v nom na skole robil par projektov.

Alebo zas len hranie sa na chrumkaveho tym, ze clovek machri nepouzivanym jazykom (ala Smalltalk)?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 02. 12. 2022, 09:29:06
Alebo zas len hranie sa na chrumkaveho tym, ze clovek machri nepouzivanym jazykom (ala Smalltalk)?

Jak to myslíte? Smalltalk se používá, stejně jako Erlang a APL jazyky, jen je to dnes malá část trhu, ale docela silná. JP Morgan má např. v (moderním) Smalltalku důležité komponenty. Dobře navržený jazyk s alespoň minimálním množstvím knihoven může spokojeně přežívat i s malou uživatelskou základnou. Někdy čím je menší, tím je stmelenější a disciplinovanější. Jen tak mudruju.  Jak jste to tedy myslel? Haskell není tak složitý, to vám potvrdím .)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 02. 12. 2022, 09:33:51
Haskell není tak složitý
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. Různá rozšíření Haskellu pak mají i GADT apod.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: honzako 02. 12. 2022, 09:43:36
To jsou všechno moc divné otázky?!
Prostě jsou hlavní "jazyky" s komerční podporou a silným zázemím, a pak je mnoho dalších ostatních, z nichž některé jsou zdarma a jsou šířeny v rámci rozšířených IDE.
Důležité je pouze to, jak je silná místní komunita např. v regionu nebo kolem konkrétní platformy/aplikace apod. No a pak už záleží jaká je osvěta a předávání "znalostí" dalším následníkům. Assembler se taky dříve používal a dnes osobně neznám nikoho kdo by ho používal.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 02. 12. 2022, 11:34:54
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í
Není, to jde vyjádřit naprosto přesně matematicky, ve formální logice nebo teorii typů (což je v podstatě intuicionistická logika).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 02. 12. 2022, 11:38:36
jestli to předchozí sáhodlouhé opěvování monád […] opravdu bylo tak užitečné, jak se tvrdilo...
Samotné opěvování je k ničemu, 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ň).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: oss 02. 12. 2022, 12:32:04
Haskell není tak složitý
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. Různá rozšíření Haskellu pak mají i GADT apod.

Ono typove triedy ani uniony niesu nicim vynimocne. A zas neprinasaju tolko. Navyse vsetky tieto veci maju svoju alternativu aj v beznom typovom systeme objektovych jazykov.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 02. 12. 2022, 13:00:47
Haskell není tak složitý
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. Různá rozšíření Haskellu pak mají i GADT apod.

Ono typove triedy ani uniony niesu nicim vynimocne. A zas neprinasaju tolko. Navyse vsetky tieto veci maju svoju alternativu aj v beznom typovom systeme objektovych jazykov.

Tak Haskell pedagogicky ukazuje, jak se dají nebo nedají věci reálného světa zakódovat do typů. Ony ty "věci" existují a fungují i bez toho Haskellu, ale dá se to na něm pěkně ilustrovat. APL mám třeba teď radši a to nepotřebuje takovou typovou teorii, přitom se kolem toho točí spousta matematiků. Pekně je vidět na Erlangu, jak si na tom "typologové" vylámali zuby, přitom evidentně přináší co slibuje, fault tolerant systems.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 02. 12. 2022, 14:47:31
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.
Je to ukazatel, že to jinak nejde (kromě toho druhého způsobu, co má Mercury, ale ten jen příliš nepraktický).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 02. 12. 2022, 14:50:08
Zajímavější metrika by byla jak často programy používají třeba free monády apod.
Co je na tom zajímavého. Volné monády (na rozdíl od těch normálních, jež jsou v podstatě triviální) jsou náročné na pochopení a přínos je dost sporný.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 02. 12. 2022, 23:03:06
Domnívám se, že hodně schází nějaký projekt, který by porovnával řešení mezi jazyky. Občas zkouším použít RosettaCode, ale je to dost zakopaný. Představoval bych si něco předžvejkanějšího. Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší. 1)



1) provokativně očekávám, že se nyní strhne lavina příspěvků, že jsem úplnej debil, ať se kouknu na tuhle a tuhle stránku, že to už přece dávno je :-)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 02. 12. 2022, 23:26:12
provokativně očekávám, že se nyní strhne lavina příspěvků, že jsem úplnej debil, ať se kouknu na tuhle a tuhle stránku, že to už přece dávno je :-)
Já o ničem takovém nevím, takže už jsme dva :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 03. 12. 2022, 08:38:44
Domnívám se, že hodně schází nějaký projekt, který by porovnával řešení mezi jazyky. Občas zkouším použít RosettaCode, ale je to dost zakopaný. Představoval bych si něco předžvejkanějšího. Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší. 1)



1) provokativně očekávám, že se nyní strhne lavina příspěvků, že jsem úplnej debil, ať se kouknu na tuhle a tuhle stránku, že to už přece dávno je :-)

Co třeba tyhle, pro začátek?

https://gist.github.com/CMCDragonkai/a5638f50c87d49f815b8
https://www.reddit.com/r/rust/comments/6seaf8/why_are_higher_kinded_types_requested_in_rust/
https://blog.rust-lang.org/2022/10/28/gats-stabilization.html
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 03. 12. 2022, 09:17:29
Domnívám se, že hodně schází nějaký projekt, který by porovnával řešení mezi jazyky. Občas zkouším použít RosettaCode, ale je to dost zakopaný. Představoval bych si něco předžvejkanějšího. Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší. 1)



1) provokativně očekávám, že se nyní strhne lavina příspěvků, že jsem úplnej debil, ať se kouknu na tuhle a tuhle stránku, že to už přece dávno je :-)

Co třeba tyhle, pro začátek?

https://gist.github.com/CMCDragonkai/a5638f50c87d49f815b8
https://www.reddit.com/r/rust/comments/6seaf8/why_are_higher_kinded_types_requested_in_rust/
https://blog.rust-lang.org/2022/10/28/gats-stabilization.html
“as an endofunctor in the category of types” ;D
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 03. 12. 2022, 09:29:22
Co třeba tyhle, pro začátek?

https://gist.github.com/CMCDragonkai/a5638f50c87d49f815b8
https://www.reddit.com/r/rust/comments/6seaf8/why_are_higher_kinded_types_requested_in_rust/
https://blog.rust-lang.org/2022/10/28/gats-stabilization.html
Se tam tvrdí, že Maybe je HKT. To je blbost, nevěřte všemu v těch odkazech.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 03. 12. 2022, 09:42:11
Z jiného soudku: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

Rust se uchytil i na Androidu: “As Android migrates away from C/C++ to Java/Kotlin/Rust, we expect the number of memory safety vulnerabilities to continue to fall. Here’s to a future where memory corruption bugs on Android are rare!”
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: linuxak 03. 12. 2022, 10:04:02
Z jiného soudku: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
To je hodně dobrá reklama na Rust. Z celého článku bych vypíchnul tohle:

To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.

Rust je paměťově bezpečný jen do té doby, než se použije unsafe. Ale zároveň z toho článku plyne, že unsafe normálně není potřeba vůbec používat. V celém UWB stacku mají použitý unsafe jen 2x z důvodu interoperability s Javou. Takže praxe ukazuje, že Rust plní to, co sliboval: paměťově bezpečný jazyk bez garbage collectoru s rychlostí C.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: mhi 03. 12. 2022, 11:50:57
Priznam se, ze jsem tema prilis necetl, mozna tu padla odpoved; prijde mi diskuse skoro jako nabozenstvi. Zeptal bych se:

1) Jake jsou nejvetsi *zname* projekty v Rustu? Chvili jsem hledal a uspokojivou odpoved na svoji otazku jsem nenasel. Mozna zdejsi znalci Rustu vytahnou seznam.

2) A jsou nejake vyznamnejsi *komercni* projekty v Rustu?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: linuxak 03. 12. 2022, 12:37:16
Priznam se, ze jsem tema prilis necetl, mozna tu padla odpoved; prijde mi diskuse skoro jako nabozenstvi. Zeptal bych se:

1) Jake jsou nejvetsi *zname* projekty v Rustu? Chvili jsem hledal a uspokojivou odpoved na svoji otazku jsem nenasel. Mozna zdejsi znalci Rustu vytahnou seznam.

2) A jsou nejake vyznamnejsi *komercni* projekty v Rustu?

Viz předchozí příspěvky, stačil by Android? Tam je Rustu docela dost: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

Linux kernel má taky docela dobře našlápnuto, ale tam se Rust teprve začíná integrovat.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: mhi 03. 12. 2022, 13:18:35
Ten clanek o Androidu je celkem vagni, nejsou tam absolutni cisla a co v tom Rustu bylo pridano. Nedokazu si z toho udelat smysluplny obrazek.

Prisib ze "ma naslapnuto" taky neberu.

Predstavoval bych si odpoved typu "Adobe v tom naprogramoval XYZ a ma to 1M uzivatelu od roku 20xx".
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: linuxak 03. 12. 2022, 13:29:32
Ten clanek o Androidu je celkem vagni, nejsou tam absolutni cisla a co v tom Rustu bylo pridano. Nedokazu si z toho udelat smysluplny obrazek.

Jak vágní, četl jsi to vůbec? Je to tam uvedeno docela přesně:

 In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust. There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies.

Nicméně absolutní čísla nejsou až tak důležitá, hlavní je trend. Google má v plánu zbavit se v dlouhodobém horizontu memory unsafe jazyků v Androidu, což znamená konec C/C++. Co je nahradí, je celkem jasné, Rust pro performance kritické části, případně Kotlin/Java tam, kde nevadí garbage collector.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Vít Šesták (v6ak) 03. 12. 2022, 13:34:06
Pokud čekáte „XY je celé v Rustu, má to Z uživatelů“, tak na to je asi příliš brzy. Velké věci budou napsané v Rustu jen z části. (Android, Gecko, Chrome?, …) Jednak velké věci často mixují více jazyků, a jednak budou procházet z doby, kdy Rust byl ještě v plenkách.


U Androidu mě napadá třeba Bluetooth: https://www.xda-developers.com/android-13-gabeldorsche-bluetooth-stack/
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 03. 12. 2022, 14:32:54
Ten clanek o Androidu je celkem vagni, nejsou tam absolutni cisla a co v tom Rustu bylo pridano. Nedokazu si z toho udelat smysluplny obrazek.

Prisib ze "ma naslapnuto" taky neberu.
Rust je ještě celkem mladý a vyvíjí se zatím dost živelně, dal bych mu ještě nějaký ten rok. Pak ho nahradí Carbon ;D
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 03. 12. 2022, 17:34:13
prijde mi diskuse skoro jako nabozenstvi.
Tak jsme z toho jazyka nadšení. Je to hřích?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 03. 12. 2022, 21:36:42
Tak jsme z toho jazyka nadšení. Je to hřích?
Smrtelný asi ne ;)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 12. 2022, 01:11:12
Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší.
U HKT je situace asi celkem jasná (aplikativní funktory a tak). 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).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 04. 12. 2022, 01:31:05
Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší.
U HKT je situace asi celkem jasná (aplikativní funktory a tak). 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).

Takhle to ale vysvětlovat nemůžeš. Pochop, lidi jsou blbý. Musíš začít takhle:

Mějme následující problém:
Chceme vytvořit čtvercovou matici přirozených čísel, kde si budeme kontrolovat, že je čtvercová. A následně nad těmito maticemi budeme vytvářet operaci, například součet. Pochopitelně chceme sčítat matice stejných velikostí.

V Pythonu to vyřešíme takto:
Kód: [Vybrat]
class Matice(object):
    def __init__(self, rows):
        self.assertSquare(rows)
        pass
    def add(self, x):
        self.assertEquals(x)
        pass

V Haskellu to vyřešíme takto:
haskell code que j'ai la flemme d'écrire

V Rustu to vyřešíme takto:
rust code que j'ai la flemme d'écrire

V Idris to vyřešíme takto:
idris code que je ne sais pas écrire

Můžete si všimnout, že v případě Pythonu to musíme ověřovat v době běhu. Zatímco v XY nám to kompilátor zajistí během překladu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 12. 2022, 01:43:31
Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší.
U HKT je situace asi celkem jasná (aplikativní funktory a tak). 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).
Takhle to ale vysvětlovat nemůžeš. Pochop, lidi jsou blbý.
Všichni nejsou blbí. Pro ty úplně blbé to psát nebudu, vždy se předpokládá určitá znalost, na které lze stavět (třeba co je konkrétní typ — “Int”, “List Int” a “Int -> Int” jsou konkrétní kupříkladu). Nejsme ve školce.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 04. 12. 2022, 02:05:40
Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší.
U HKT je situace asi celkem jasná (aplikativní funktory a tak). 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).
Takhle to ale vysvětlovat nemůžeš. Pochop, lidi jsou blbý.
Všichni nejsou blbí. Pro ty úplně blbé to psát nebudu, vždy se předpokládá určitá znalost, na které lze stavět (třeba co je konkrétní typ — “Int”, “List Int” a “Int -> Int” jsou konkrétní kupříkladu). Nejsme ve školce.

Tohle znáš? http://naucte-se.haskell.cz/kapitoly

Lidi jsou blbý. Kolika profesionálním 1) programátorům jsem vysvětloval, co je to rozhraní a k čemu je to dobrý.

Buď jsi elitář 2), a nebo chceme, aby ty jazyky používali lidi v průmyslu.



1) Profesionální znamená, že se tím živili.
2) Nikdo tě samozřejmě nenutí, aby si to vysvětloval zrovna ty, pokud se ti nechce. Ale vysvětlovat jak ve školce je třeba, sorry jako.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 12. 2022, 04:48:41
Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší.
U HKT je situace asi celkem jasná (aplikativní funktory a tak). 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).
Takhle to ale vysvětlovat nemůžeš. Pochop, lidi jsou blbý.
Všichni nejsou blbí. Pro ty úplně blbé to psát nebudu, vždy se předpokládá určitá znalost, na které lze stavět (třeba co je konkrétní typ — “Int”, “List Int” a “Int -> Int” jsou konkrétní kupříkladu). Nejsme ve školce.

Tohle znáš? http://naucte-se.haskell.cz/kapitoly

Lidi jsou blbý.
Kdysi jsem to viděl. Tady ale nešlo o vysvětlování, ale porovnání jazyků, ne? Na to jsem reagoval. Jinak samozřejmě ano, určitě je žádoucí mít někde polopatický popis GADT apod. Na ten úvod do Haskellu by šlo asi plynule navázat.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Rike 04. 12. 2022, 10:08:26
Rust je ještě celkem mladý a vyvíjí se zatím dost živelně, dal bych mu ještě nějaký ten rok. Pak ho nahradí Carbon ;D
Zajímavá aktivita Googlu, ale je po tom taková poptávka, aby to překročilo brány firmy? Těch projektů takhle víc zašlo než se udrželo.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 04. 12. 2022, 10:25:13
Tady ale nešlo o vysvětlování, ale porovnání jazyků, ne? Na to jsem reagoval. Jinak samozřejmě ano, určitě je žádoucí mít někde polopatický popis GADT apod. Na ten úvod do Haskellu by šlo asi plynule navázat.
Jde o to, že když ti číňan, když už si půjčíme to otřepané přirovnání, začne čínsky vysvětlovat, že oni by to řekli takhle hezky... Dokavad neumíš čínsky, tak to neoceníš, a když už umíš čínsky, tak to nepotřebuješ.

Já třeba hodně zhruba rozumím té syntaxi, kterou jsi použil, protože třeba Haskel, nebo OCaml cca znám. Taky hodně zhruba vím, co to to GADT je (spíše méně, než více). A přesto mi ten tvůj příklad vůbec k ničemu nebyl. To jsi chtěl?

Jinak samozřejmě ano, určitě je žádoucí mít někde polopatický popis GADT apod. Na ten úvod do Haskellu by šlo asi plynule navázat.
Já tě jinak chci vyprovokovat, třeba něco napsat :-)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: linuxak 04. 12. 2022, 10:30:01
Zajímavá aktivita Googlu, ale je po tom taková poptávka, aby to překročilo brány firmy? Těch projektů takhle víc zašlo než se udrželo.
Carbon v Google vzniknul primárně ze dvou důvodů:

Carbon je zajímavý počit, ale jedním z jeho primárních cílů byla dobrá interoperabilita s existujícím C++ kódem, což dost omezuje při návrhu jazyka, nemohli to prostě udělat celé od základu jinak (jak to udělal třeba Rust). Google má spoustu existujícího kódu v C++ a nemůže si dovolit všechno zahodit a přepsat, proto potřebuje jazyk, ze kterého půjde volat existující C++ kód. Důsledem je, že Carbon v součané podobě není memory safe. Někdy možná bude, ale vyžádalo by si to zpětně nekompatibilní změny v designu jazyka. Takže pocity z Carbonu jsou zatím spíš rozpačité, oproti C++ je to posun vpřed, ale zároveň je to takové polovičané řešení, primárně kvůli požadavku na interoperabilitu s C++.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 04. 12. 2022, 10:32:01
Zajímavá aktivita Googlu, ale je po tom taková poptávka, aby to překročilo brány firmy? Těch projektů takhle víc zašlo než se udrželo.
Carbon v Google vzniknul primárně ze dvou důvodů:

  • Bezpečnost C++ je hrozná, Carbon tohle (částečně) řeší.
  • C++ steering committee dlohodobě ignorovala snahy Google o rozbití ABI, což Google považuje za nutné k dalšímu rozvoji C++ (tady jsem na straně Google).
Carbon je zajímavý počit, ale jedním z jeho primárních cílů byla dobrá interoperabilita s existujícím C++ kódem, což dost omezuje při návrhu jazyka, nemohli to prostě udělat celé od základu jinak (jak to udělal třeba Rust). Google má spoustu existujícího kódu v C++ a nemůže si dovolit všechno zahodit a přepsat, proto potřebuje jazyk, ze kterého půjde volat existující C++ kód. Důsledem je, že Carbon v součané podobě není memory safe. Někdy možná bude, ale vyžádalo by si to zpětně nekompatibilní změny v designu jazyka. Takže pocity z Carbonu jsou zatím spíš rozpačité, oproti C++ je to posun vpřed, ale zároveň je to takové polovičané řešení, primárně kvůli požadavku na interoperabilitu s C++.

Když to porovnáš s Dlang? Lepší, horší, jiné?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: alex6bbc 04. 12. 2022, 11:31:43
Zajímavá aktivita Googlu, ale je po tom taková poptávka, aby to překročilo brány firmy? Těch projektů takhle víc zašlo než se udrželo.
Carbon v Google vzniknul primárně ze dvou důvodů:

  • Bezpečnost C++ je hrozná, Carbon tohle (částečně) řeší.
  • C++ steering committee dlohodobě ignorovala snahy Google o rozbití ABI, což Google považuje za nutné k dalšímu rozvoji C++ (tady jsem na straně Google).
Carbon je zajímavý počit, ale jedním z jeho primárních cílů byla dobrá interoperabilita s existujícím C++ kódem, což dost omezuje při návrhu jazyka, nemohli to prostě udělat celé od základu jinak (jak to udělal třeba Rust). Google má spoustu existujícího kódu v C++ a nemůže si dovolit všechno zahodit a přepsat, proto potřebuje jazyk, ze kterého půjde volat existující C++ kód. Důsledem je, že Carbon v součané podobě není memory safe. Někdy možná bude, ale vyžádalo by si to zpětně nekompatibilní změny v designu jazyka. Takže pocity z Carbonu jsou zatím spíš rozpačité, oproti C++ je to posun vpřed, ale zároveň je to takové polovičané řešení, primárně kvůli požadavku na interoperabilitu s C++.

google si mohl udelat svuj C++G, ohnout kompiler a nekompatibilne ohnout C++.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: mhi 04. 12. 2022, 12:14:53
prijde mi diskuse skoro jako nabozenstvi.
Tak jsme z toho jazyka nadšení. Je to hřích?

Neni. Ne ze by mne nezajimala psychologie za tim co se deje okolo Rustu, ale toho se zde asi nedobereme. Zajimaji mne na tomto serveru technicke veci, takze bych rad overitelna fakta.

Take mi neni uplne jasne, proc svet nesel jen rozsirenim jazyka C o vlastnosti, ktere by resily problem memory unsafe jazyka (tzn. stale by to bylo na programatorovi, zda pouzije cisty pointer a tim udela memory unsafe program).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 04. 12. 2022, 12:27:52
Neni. Ne ze by mne nezajimala psychologie za tim co se deje okolo Rustu, ale toho se zde asi nedobereme.

To je stejná psychologie, jako když jsi půl života musel tahat kamení za sebou na kárce a pak jsi dostal náklaďák.

Citace
Take mi neni uplne jasne, proc svet nesel jen rozsirenim jazyka C o vlastnosti, ktere by resily problem memory unsafe jazyka (tzn. stale by to bylo na programatorovi, zda pouzije cisty pointer a tim udela memory unsafe program).

Tohle v různých obdobách existuje dávno. Očividně se to zase tolik neosvědčilo a proto "svět" vymyslel třeba Rust, kde udělat program unsafe je možné, ale má to svoje pravidla a obecně se to nedoporučuje.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: ondra05 04. 12. 2022, 13:25:56
A jsou tu i navíc lidé kteří nechtějí C. C je přeceňovaný jazyk z pochybným designem, tak už by stálo za to udělat něco pořádného, ne?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: mhi 04. 12. 2022, 13:49:46
Neni. Ne ze by mne nezajimala psychologie za tim co se deje okolo Rustu, ale toho se zde asi nedobereme.
To je stejná psychologie, jako když jsi půl života musel tahat kamení za sebou na kárce a pak jsi dostal náklaďák.

Bavime se s tou psychologii kazdy o necem jinem, ale to je tema mimo tento server, do ktereho nechci zabredat vic, nez ze by to u mnoha lidi mohl byt "ego-obranny mechanismus".

Ja rozhodne v cecku nevidim karku, ale prave naopak v mnoha "modernich" jazycich vidim spis "moderni auto ktere prinasi vic problemu nez uzitku". Bohuzel to jsou i novejsi C++, ktere se myslim uzaviraji do vlastniho sveta "reseni problemu ktere sam jazyk prinesl".

Citace
Take mi neni uplne jasne, proc svet nesel jen rozsirenim jazyka C o vlastnosti, ktere by resily problem memory unsafe jazyka (tzn. stale by to bylo na programatorovi, zda pouzije cisty pointer a tim udela memory unsafe program).
Tohle v různých obdobách existuje dávno. Očividně se to zase tolik neosvědčilo a proto "svět" vymyslel třeba Rust, kde udělat program unsafe je možné, ale má to svoje pravidla a obecně se to nedoporučuje.

Muzete mi dat priklad toho rozsireni C o memory safe reseni ?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Ink 04. 12. 2022, 14:29:45
Citace
Tohle v různých obdobách existuje dávno. Očividně se to zase tolik neosvědčilo a proto "svět" vymyslel třeba Rust, kde udělat program unsafe je možné, ale má to svoje pravidla a obecně se to nedoporučuje.

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

C++ obsahuje prvky memory safety, C++ je přece rozšířené C. A podobných jazyků je víc.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: linuxak 04. 12. 2022, 14:30:26
Bavime se s tou psychologii kazdy o necem jinem, ale to je tema mimo tento server, do ktereho nechci zabredat vic, nez ze by to u mnoha lidi mohl byt "ego-obranny mechanismus".
To je docela zajímavé téma a přijde mi, že obranný mechanismus je na obou stranách. Hodně lidí z C/C++ komunity vidí v Rustu ohrožení, protože se může stát, že Rust C/C++ v budoucnu nahradí. Lidé obecně nemají rádi změny a drží se toho, co znají, to je normální lidské chování. Takže se Rustu logicky brání. Naopak lidé z Rust komunity na ně tlačí někdy až moc agresivně, což vede řekněme k různým nedorozuměním.

Ja rozhodne v cecku nevidim karku, ale prave naopak v mnoha "modernich" jazycich vidim spis "moderni auto ktere prinasi vic problemu nez uzitku". Bohuzel to jsou i novejsi C++, ktere se myslim uzaviraji do vlastniho sveta "reseni problemu ktere sam jazyk prinesl".
Problémem C je, že má na svědomí asi tak 90% kritických bezpečnostních chyb kvůli tomu, že je memory unsafe. Google uvádí, že dle jeho statistik připadá jedna bezpečnostní chyba na 1000 řádek C kódu. To je strašné číslo a nejde s tím nic dělat, protože ty chyby způsobuje lidský faktor. Lidé prostě nejsou schopni psát v C bez chyb. Takže jediné řešení je zbavit se C a použít memory safe jazyk. Tím zmizí 90% kritických bezpečnostních chyb.

Muzete mi dat priklad toho rozsireni C o memory safe reseni ?
Z C není možné udělat memory safe jazyk bez ztráty zpětné kompatibility. C by se muselo hodně předělat a vzniklo by něco podobného Rustu. Proto takové snahy nemají smysl, lepší je začít znovu a C nechat být. Tady nejde jít cestou evoluce, revoluční změna je nutná.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: mhi 04. 12. 2022, 15:22:32
Pokud jde o ty ego-obrany, myslim to asi trosku jinak.

Nevim jaky maji pocit lide "tlacici" Rust, rekl bych, ze jejich pocit muze byt z vetsi casti "mam skvely jazyk ktery vsem ukaze jak jsou/byli blbi" (a tim i "a jak ja to umim").

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. Takze bude-li podminkou prekladu kernelu mit Rust prekladac a resit nejake zavislosti, knihovny, apod., tak se to stava i mym problemem, ktery musim resit, bez pro mne pridane hodnoty.



Abych dal priklad odjinud, nektere zmeny v novejsich gcc ve spojeni s C++11 privedly neprelozitelnost cele rady zdrojaku (nejen mych :) ). Takze na to, abych je mohl prelozit jsem musel mechanicky opravit stovky radek kodu. Paradoxne neco z toho po zprocesovani indentem se zaneslo zpatky (operator "" ). Zbytecne ztraceny cas jen kvuli tomu, ze nekdo si nedokaze predstavit ze stale existuje C99 kod. Tohle mi neskutecne vadi.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: linuxak 04. 12. 2022, 15:49:21
Pokud jde o ty ego-obrany, myslim to asi trosku jinak.

Nevim jaky maji pocit lide "tlacici" Rust, rekl bych, ze jejich pocit muze byt z vetsi casti "mam skvely jazyk ktery vsem ukaze jak jsou/byli blbi" (a tim i "a jak ja to umim").
Myslím, že to trochu jinak. Pokud já někam tlačím Rust (obecně to nedělám moc rád), tak je to stylem "mám skvělý jazyk, který řeší spoustu bezpečnostních problémů, které jsou v C/C++ a je stejně rychlý". Ale i tohle se samozřejmě potkává s odporem, protože lidé změny moc nechtějí, to je přirozená lidská vlastnost.

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. Takze bude-li podminkou prekladu kernelu mit Rust prekladac a resit nejake zavislosti, knihovny, apod., tak se to stava i mym problemem, ktery musim resit, bez pro mne pridane hodnoty.
V Linuxu bylo za dobu jeho existence objeveno asi 800 chyb souvisejících se špatnou práci s pamětí, většina s dopadem na bezpečnost (remote code execution, gain information...). A to se bavíme jen o známých chybách, těch zatím neobjevených bude řádově více. Žádná z těchto chyb v kernelu nebyla, pokud by se použil memory safe jazyk. Ty v tom možná nevidíš přidanou hodnotu, jiní lidé ale ano.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 12. 2022, 16:35:34
Já tě jinak chci vyprovokovat, třeba něco napsat :-)
Jdeš na to fikaně ;) Zrovna GADT nejsou žádná věda. Když definuju (běžný) ADT, určím typ, například “List a”, a k němu konstruktory. V případě GADT se určí typ pro každý konstruktor zvlášť. V případě “Vect” (Nat -> Type -> Type, Nat je typ přirozených čísel) mám konstruktor “Nil” typu “Vect 0 a” (ta nula je délka vektoru) a druhý konstruktor “Cons” typu “a -> Vect n a -> Vect (n+1) a”. To ADT neumí, protože jednou tam je nula a jednou “n+1”.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: mhi 04. 12. 2022, 17:24:21
Myslím, že to trochu jinak. Pokud já někam tlačím Rust

V Linuxu bylo za dobu jeho existence objeveno asi 800 chyb souvisejících se špatnou práci s pamětí, Žádná z těchto chyb v kernelu nebyla, pokud by se použil memory safe jazyk. Ty v tom možná nevidíš přidanou hodnotu, jiní lidé ale ano.

ad ego obrany: jejich "kouzlo" je, ze ten kdo je pouziva "nenahledne za ne", jinak by mu prestaly fungovat. Ja osobne na to jdu metodou, ze se zeptam "co by se stalo kdyby ...<proti cemu se domnele branim>". Zracionalizovat si dokazeme vsichni asi skoro vsechno, dokud se to nebije uplne s realitou. Psychotici tedy dokazou i to :).

Verim tomu, ze i Lennart Poettering veri, ze prinasi dobro v systemd. Ja si o nem na oplatku zase myslim, ze systemd je takova jeho narcistni ego-obrana pred jeho vlastnim pocitem menecennosti.

Pokud jde o nutnost memory safe jazyku, s tim nepolemizuju, akorat stale nejsem presvedcen, ze cesta je prave pres Rust.

Rekl bych, ze treba reseni kernelu bude spis ve zmene paradigmatu, SystemV/BSD kernel ma prilis mnoho nedostatku.

Uz jsem dost offtopic, tak se omlouvam.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 04. 12. 2022, 20:07:40
Pokud jde o nutnost memory safe jazyku, s tim nepolemizuju, akorat stale nejsem presvedcen, ze cesta je prave pres Rust.

Pokud si jako kritérium vezmeš memory safe, tak ačkoliv Rust není dokonalý, tak čím by si mu chtěl konkurovat? (Bavíme se o nízkoúrovňovém jazyku. Na nějaké appky vždycky můžeš použít Javu, samozřejmě.) Jaké máš výhrady, nebo očekávání?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 04. 12. 2022, 20:21:32
Pokud jde o nutnost memory safe jazyku, s tim nepolemizuju, akorat stale nejsem presvedcen, ze cesta je prave pres Rust.

Pokud si jako kritérium vezmeš memory safe, tak ačkoliv Rust není dokonalý, tak čím by si mu chtěl konkurovat? (Bavíme se o nízkoúrovňovém jazyku. Na nějaké appky vždycky můžeš použít Javu, samozřejmě.) Jaké máš výhrady, nebo očekávání?
Spark?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: kanoe22 04. 12. 2022, 21:19:46
...
Abych dal priklad odjinud, nektere zmeny v novejsich gcc ve spojeni s C++11 privedly neprelozitelnost cele rady zdrojaku (nejen mych :) ). Takze na to, abych je mohl prelozit jsem musel mechanicky opravit stovky radek kodu. Paradoxne neco z toho po zprocesovani indentem se zaneslo zpatky (operator "" ). Zbytecne ztraceny cas jen kvuli tomu, ze nekdo si nedokaze predstavit ze stale existuje C99 kod. Tohle mi neskutecne vadi.

Nikdy nepochopim tuto ideu, ked raz nieco napisem v nejakom jazyku a ten jazyk funguje a vyvyja sa dalsie desatrocia, tak to stale musi ist prelozit aj najnovsou verziou jazyka? Moja odpoved je nie.
Pretoze nove verzie jazyka (akehokolvek jazyka, aj c++) musia mat moznost priniest breaking changes, ak to treba pre vyvoj jazyka. Inak sa z akehokolvek jazyka stava v momente jeho vytvorenia jazyk s obmedzenou dobou pouzitia, pretoze jedneho dna budu tvorcovia stat pred otazkou, ci pridat podporu nejakych novych ficur/principov/..., alebo nechat jazyk padnut na hnojisko dejin.
Riskovat to vsetko len kvoli tomu aby si nejaky franta z hornej dolnej vedel skompilovat svoj 40rokov stary kod s najnovsou verziou jazyka? Ak chcete pouzivat desiatky rokov stary kod a modifikovat ho, tak ho za A bud potrebujete aktualizovat do dnesnych standardov, alebo za B pouzivat dobovu techniku/technologiu.

Kazdy z nas ma zarucene predkov ktori zili 10 000 rokov dozadu, inak by sme neexistovaly pretoze casova kauzalita proste nepusti. Pred 10 000 rokmi ale ludia hovorili inymi jazykmi, ak vobec nejake mali, ak to neboli (pre nas z dnesneho pohladu) iba nejake pazvuky, hmkanie, mlaskanie a co ja viem co dalsie.
To ze dnes pouzivame ine jazyky, ktore su nekompatibilne s jazykmi starymi 10k rokov, znamena ze mame dnesne jazyky zahodit? Pretoze zaznamy stare 10k rokov sa nedaju precitat dnesnymi jazykmi, pretoze dnesne jazyky (neratam nejake kmene s 50timi obyvatelmi uprostred amazonie zaseknute v case) nepouzivaju mlaskanie a hmkanie na dorozumievanie, ale artikulovane slabiky vytvarajuce slova -> chces pouzivat stare veci v dnesnom svete, bud ich upgraduj, alebo sa zmier s tym ze musis pouzivat dobove veci (v tomto pripade verziu jazyka/kompilatora z ery toho programu)

Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 04. 12. 2022, 22:50:06
Pred 10 000 rokmi ale ludia hovorili inymi jazykmi, ak vobec nejake mali, ak to neboli (pre nas z dnesneho pohladu) iba nejake pazvuky, hmkanie, mlaskanie a co ja viem co dalsie.

Navzdory tomu, že té argumentaci rozumím a souhlasím, a abych si udržel špatnou pověst, tak si neodpustím rejp: Není jediný důkaz toho, že by se jazyky vyvíjeli. Když porovnáš nejstarší jazyk Egyptštinu a porovnáš s libovolným moderním jazykem, tak jsou tam sice změny, ale ne kvalitativní (něco se sofistikuje, něco se zjednodušuje). Tvrzení, že na začátku bylo mlaskání a krkání je tvrzení založené na tom, že to tak přece muselo být.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Rike 04. 12. 2022, 23:10:47
Před 10 tisíci lety, to je zemědělství a sídlištní kultury, takže určitě žádné mlaskání a hekání  ;)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 04. 12. 2022, 23:14:19
"Tvrzení, že na začátku bylo mlaskání a krkání je tvrzení založené na tom, že to tak přece muselo být." Tak letmý pohled na naše příbuzné by tomu napovídal. Mluvidla se zřejmě vyvíjel společně s řečí. Krkáním bych to tedy nenazval, ale zvukový repertoár se jistě obohacoval. Co myslíte tím "nestarší jazyk Egyptštinu..."?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 04. 12. 2022, 23:17:05
Před 10 tisíci lety, to je zemědělství a sídlištní kultury, takže určitě žádné mlaskání a hekání  ;)

 V milionech to skoro trefil. Evoluční biologie na škole byla? U nás i paleontologie (VŠ) :D
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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ě.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 02:41:09
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).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 02:48:51
Přiznám se, že tyhle komentáře mě poněkud iritují
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á).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 03:07:30
určitě žádné mlaskání
Mlaskat klidně mohli, v Africe se mlaská dodnes (viz lingvistický pojem “mlaskavka”) :) Koho současné poznání vývoje lidských jazyků zajímá, může si přečíst něco od Dietera Wunderlicha nebo Jerryho Hobbse, ti to popisují srozumitelně i pro laiky. Podle Chomského k vývoji dnešního typu jazyka došlo před 70000-100000 lety a od té doby se jazykový systém nezměnil (mění se slovní zásoba a tvarosloví, ne strukturní principy), to je ale jen jedna z hypotéz.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: oss 05. 12. 2022, 08:53:58
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...

Casto je to len o egu, nie o praktickych dosledkoch. Keby mali tie super jazyky take super vyhody ako sa hovori, tak ich uz pouzivame vsade?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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 :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 11:14:56
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
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í).

A ještě jednou pro ty pomalejší, borrowing ani GC nijak nesouvisí s typovým systémem.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 11:32:48
Já třeba hodně zhruba rozumím té syntaxi, kterou jsi použil, protože třeba Haskel, nebo OCaml cca znám. […] Já tě jinak chci vyprovokovat, třeba něco napsat :-)
Myslím, že kdysi jsme se bavili o pokročilých typech na příkladu definice sudosti na úrovni typů. Ten příslušný typ “IsEven” je vlastně taky GADT, klidně to můžeme rozebrat znova z tohoto úhlu, jestli si myslíš, že to bude pro tebe přínosné. Akorát to nebudu psát z mobilu, to je vopruz :-\ takže spíš až večer.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 12:21:20
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.
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í. Například Idris nebo Lean umí transpilaci do C, kde není runtime pro typy ani GC, veškerou kontrolu oddře překladač a když usoudí, že je kód typově správně, vyplivne výstup bez typových parametrů, ty právě slouží pouze ke statické kontrole.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 12:23:38
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 (ostatně mají ji i dynamické jazyky, které typy při překladu vůbec neřeší).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 13:24:50
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.).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 13:26:23
Tohle Rust a C++ nemůžou udělat, protože nemůžou narozdíl od Idrisu libovolnou hodnotu implicitně boxovat
Po tisící, Idris nic neboxuje, umí si to ověřit při překladu v rámci statické typové kontroly.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 13:32:42
co přesně ti není jasné na těch příkladech, které jsem uvedl?
Jsou zcela irelevantní, vůbec se netýkají tématu. Kdybych escape analýzu, jak ji dělá Java nebo Go, použil pro borrow checking, bude to krásně fungovat i bez lifetimů jako typových parametrů. Rust má jen ten borrow checking o něco chytřejší, je to ostatně jeho jediná výhoda oproti srovnatelným jazykům.

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).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 14:30:30
Borrow checking je jedna z fází typové kontroly
  ::)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 15:16:38
(Kdyžtak pls ukázku, jak tohle specifikuju bez typového systému.)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 15:49:29
Já třeba hodně zhruba rozumím té syntaxi, kterou jsi použil, protože třeba Haskel, nebo OCaml cca znám. […] Já tě jinak chci vyprovokovat, třeba něco napsat :-)
Myslím, že kdysi jsme se bavili o pokročilých typech na příkladu definice sudosti na úrovni typů. Ten příslušný typ “IsEven” je vlastně taky GADT, klidně to můžeme rozebrat znova z tohoto úhlu, jestli si myslíš, že to bude pro tebe přínosné. Akorát to nebudu psát z mobilu, to je vopruz :-\ takže spíš až večer.
Už si bohužel nepamatuju, jak daleko jsme se tehdy dostali, ale opakování matka moudrosti ;)

Typ IsEven má (meta)typ Nat -> Type (je to tedy typový konstruktor), v podstatě je to "funkce" (funkce na úrovni typů), která dostane přirozené číslo (Nat je induktivní typ, to teď asi není důležité) a vrátí typ. Potud asi jasné (?). Hlavička definice tedy bude
Kód: [Vybrat]
data IsEven : Nat -> Type where
Tento typ má dva konstruktory, řekněme ZIsEven a SuccSuccIsEven, které generují hodnoty různých typů (proto se jedná o GADT), ten první je typu IsEven 0 a ten druhý typu IsEven (n+2) pro nějaké přirozené číslo n.

Tady zastavím a počkám na tvůj feedback ;)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 16:02:11
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. ... ale jakmile bude to bude složitější, nepůjde to.
Nějakou dobu jsem si hrál s Amulet ML, který kompiloval statickej kód do Luy. Díky tomu j sem si mohl vcelku rozumě prohlédnout, co to vymejšlelo. Na základě této zkušenosti ti nemohu dát za pravdu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 16:08:01
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. ... ale jakmile bude to bude složitější, nepůjde to.
Nějakou dobu jsem si hrál s Amulet ML, který kompiloval statickej kód do Luy. Díky tomu j sem si mohl vcelku rozumě prohlédnout, co to vymejšlelo. Na základě této zkušenosti ti nemohu dát za pravdu.
Já mam na mysli tu situaci, kdy zkonstruuješ parametrizovaný typ jako např. ten vektor nebo matici dynamicky ze vstupních dat. Lua úplně není dobrej příklad, protože to je dynamicky typovaný jazyk, tj. pochopitelně obsahuje runtime typové informace. Spíš by bylo lepší se podívat na ten C výstup.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 16:10:59
Já třeba hodně zhruba rozumím té syntaxi, kterou jsi použil, protože třeba Haskel, nebo OCaml cca znám. […] Já tě jinak chci vyprovokovat, třeba něco napsat :-)
Myslím, že kdysi jsme se bavili o pokročilých typech na příkladu definice sudosti na úrovni typů. Ten příslušný typ “IsEven” je vlastně taky GADT, klidně to můžeme rozebrat znova z tohoto úhlu, jestli si myslíš, že to bude pro tebe přínosné.
Mám o to zájem, a předem děkuji.

Už si bohužel nepamatuju, jak daleko jsme se tehdy dostali, ale opakování matka moudrosti ;)
Dost mi to dalo, ale jak říkáš. Hlavně jsme se točily kolem forall, to bylo v tu dobu pro mě hodně zajímavé.

Typ IsEven má (meta)typ Nat -> Type (je to tedy typový konstruktor), v podstatě je to "funkce" (funkce na úrovni typů), která dostane přirozené číslo (Nat je induktivní typ, to teď asi není důležité) a vrátí typ. Potud asi jasné (?). Hlavička definice tedy bude
Kód: [Vybrat]
data IsEven : Nat -> Type where
Tento typ má dva konstruktory, řekněme ZIsEven a SuccSuccIsEven, které generují hodnoty různých typů (proto se jedná o GADT), ten první je typu IsEven 0 a ten druhý typu IsEven (n+2) pro nějaké přirozené číslo n.

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>
případně:
Kód: [Vybrat]
type IsEven<T> where T is Nat
?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 16:16:42
Typ IsEven má (meta)typ Nat -> Type (je to tedy typový konstruktor), v podstatě je to "funkce" (funkce na úrovni typů), která dostane přirozené číslo (Nat je induktivní typ, to teď asi není důležité) a vrátí typ. Potud asi jasné (?). Hlavička definice tedy bude
Kód: [Vybrat]
data IsEven : Nat -> Type where
Tento typ má dva konstruktory, řekněme ZIsEven a SuccSuccIsEven, které generují hodnoty různých typů (proto se jedná o GADT), ten první je typu IsEven 0 a ten druhý typu IsEven (n+2) pro nějaké přirozené číslo n.

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>
případně:
Kód: [Vybrat]
type IsEven<T> where T is Nat
?

Zatím v ničem. Pro GADT jsou relevantní až ty konstruktory hodnot.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 16:22:09
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. ... ale jakmile bude to bude složitější, nepůjde to.
Nějakou dobu jsem si hrál s Amulet ML, který kompiloval statickej kód do Luy. Díky tomu j sem si mohl vcelku rozumě prohlédnout, co to vymejšlelo. Na základě této zkušenosti ti nemohu dát za pravdu.
Já mam na mysli tu situaci, kdy zkonstruuješ parametrizovaný typ jako např. ten vektor nebo matici dynamicky ze vstupních dat. Lua úplně není dobrej příklad, protože to je dynamicky typovaný jazyk, tj. pochopitelně obsahuje runtime typové informace. Spíš by bylo lepší se podívat na ten C výstup.
C je bordel na kolečkách. S tím se odmítám zabejvat.

Není podstatné, že Lua je dynamický jazyk. Chtěl jsem tím uvést, že když jsem se kouknul do toho zdrojáku, tak tam žádné typové informace, které tvrdíš, že tam musí zůstat aby něco, nebyly. Prostě Amulet vzal ty typové informace, provedl z toho transformaci na Luu, a všechny ostatní věci zahodil.

Co se týče toho vtable, na které jsi narážel - tomu se mi nechce věřit. To je nějaké matení. Protože:
1/ Jistě, Haskell má své hranice, a některé věci prostě už neutáhne compiletime, a tak se ty věci, které nejdou, převedou do runtime - v tomto samozřejmě souhlas.
2/ Cílem je, abychom dosáhli situace, kdy všechny věci budou podchyceny v compiledtime. Viz Idris.
3/ Výsledný kód nemusí nutně záviset na runtime - to je to tvrzení, které rozporuji.
4/ Já se neodvažuji tvrdit, zda borrowing je otázka typu nebo ne. Ale každopádně si představuji, že když dám v Rustu x.get_borrow() tak mi to může udělat různé věci. Od nějaké lokální proměnný, kde bude uchovanej výsledek, přes volání nějaké runtime obsluhy. Nic není daný musem.
5/ Samozřejmě, nikde nic nemusí být boxované, nebo boxovatelné.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 16:28:44
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.
Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Já té formulaci asi nerozumím.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 17:00:25
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.
Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Dobře, tak mějme ten příklad s maticí. Dejme tomu, že od nějaké velikosti Thr (jako threshold) používá implementace matice nějakou vymakanou reprezentaci v paměti kvůli ušetření místa pro velké matice. Ok? Teď dejme tomu, že máme operaci `col` na matici, která vrátí daný sloupec jako vektor. Tahle operace bude muset fungovat různě v závislosti na Thr, z úsporné reprezentace se čte sloupec jinak než z jednoduché.

Tak, a teď, ty napíšeš program, který načte matici ze souboru a bude chtít číst sloupce. Pokud by ta typová informace - v tomto případě velikost matice - byla komplet odstraněna, metoda `col` by neměla jak poznat, jak je konkrétní matice v paměti reprezentována, a tedy jak extrahovat sloupec. Proto bude muset ta matice si s sebou tu informaci vzít a držet si ji během runtime, buďto to může být nějaký tag, podle kterého udělá ta metoda `col` vidličku, anebo si s sebout vezme vtable, která bude u různých konkrétních hodnoty ukazovat na různé implementace `col`. Řešení s vtable je obecnější - těch typových parametrů může být více, chování se může v závislosti na nich více lišit.

V jazyce jako Rust nebo C++ tohle není potřeba, protože kompilátor zná dopředu všechny instanciace a provede monomofrizaci, ie. v podstatě z toho udělá různé typy s různými metodami, ale cena za to je, že není možné vytvořit tu hodnotu at runtime.

Není podstatné, že Lua je dynamický jazyk. Chtěl jsem tím uvést, že když jsem se kouknul do toho zdrojáku, tak tam žádné typové informace, které tvrdíš, že tam musí zůstat aby něco, nebyly.
Jak jsi poznal, že tam nebyly typové informace? V jazyce jako Lua má každá hodnota runtime typovou informaci, tak fungují dynamicky typované jazyky, tzn. ty typy tam nemohly nebýt :)

---

Jinak podíval jsem se na C výstup Idris kompilátoru a je to prostě VM (verze idris je u mě 1.3.4). Toto je funkce alokující hodnotu, okopírováno z Idris runtime:

Kód: [Vybrat]
static inline Con * allocConF(VM * vm, uint32_t tag, uint16_t arity, int outer) { ... }
Hádejte, co je `tag` :D
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 17:10:47
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.
Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Já té formulaci asi nerozumím.
Tak tak. Ta formulace je blábol, nedává to vůbec smysl.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 17:18:24
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.
Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Já té formulaci asi nerozumím.
Tak tak. Ta formulace je blábol, nedává to vůbec smysl.
A byl by nějaký argument? Na co by mi proboha prosím byl vtable, pokud nedělám type erasure? Přesně z toho důvodu, že jazyky jako C++ nebo Rust nedělají type erasure generik (místo toho monomofrigzují) nepotřebují vtables, narozdíl třeba od Javy.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 17:20:47
Jinak podíval jsem se na C výstup Idris kompilátoru a je to prostě VM (verze idris je u mě 1.3.4). Toto je funkce alokující hodnotu, okopírováno z Idris runtime:

Kód: [Vybrat]
static inline Con * allocConF(VM * vm, uint32_t tag, uint16_t arity, int outer) { ... }
Hádejte, co je `tag` :D
Není to to, co si myslíš. A Idris 1 dávno není podporován, smysl dává jen použití jen Idrisu 2 (relevantní backend je "refc").
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 17:26:08
Na co by mi proboha prosím byl vtable, pokud nedělám type erasure? Přesně z toho důvodu, že jazyky jako C++ nebo Rust nedělají type erasure generik (místo toho monomofrigzují) nepotřebují vtables, narozdíl třeba od Javy.
Jazyky jako Idris a Lean (a pár dalších) dělají type erasure a vtables v generovaném kódu taky nepoužívají.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 17:30:55
Na co by mi proboha prosím byl vtable, pokud nedělám type erasure? Přesně z toho důvodu, že jazyky jako C++ nebo Rust nedělají type erasure generik (místo toho monomofrigzují) nepotřebují vtables, narozdíl třeba od Javy.
Jazyky jako Idris a Lean (a pár dalších) dělají type erasure a vtables v generovaném kódu taky nepoužívají.

No ano, protože ty hodnoty tagují, jak jsem viděl (v kódu všude velké switche na tagy).

Idris2 se mi instaluje, jak si z něj vygeneruju C kód pomocí 'refc' backendu?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 17:31:22
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 17:34:15
Není podstatné, že Lua je dynamický jazyk. Chtěl jsem tím uvést, že když jsem se kouknul do toho zdrojáku, tak tam žádné typové informace, které tvrdíš, že tam musí zůstat aby něco, nebyly.
Jak jsi poznal, že tam nebyly typové informace? V jazyce jako Lua má každá hodnota runtime typovou informaci, tak fungují dynamicky typované jazyky, tzn. ty typy tam nemohly nebýt :)
Na vstupu bylo x = Red. V lue bylo x = 1. To považuji, že tam ten Red není.


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.
Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Dobře, tak mějme ten příklad s maticí. Dejme tomu, že od nějaké velikosti Thr (jako threshold) používá implementace matice nějakou vymakanou reprezentaci v paměti kvůli ušetření místa pro velké matice. Ok? Teď dejme tomu, že máme operaci `col` na matici, která vrátí daný sloupec jako vektor. Tahle operace bude muset fungovat různě v závislosti na Thr, z úsporné reprezentace se čte sloupec jinak než z jednoduché.

Tak, a teď, ty napíšeš program, který načte matici ze souboru a bude chtít číst sloupce. Pokud by ta typová informace - v tomto případě velikost matice - byla komplet odstraněna, metoda `col` by neměla jak poznat, jak je konkrétní matice v paměti reprezentována, a tedy jak extrahovat sloupec. Proto bude muset ta matice si s sebou tu informaci vzít a držet si ji během runtime, buďto to může být nějaký tag, podle kterého udělá ta metoda `col` vidličku, anebo si s sebout vezme vtable, která bude u různých konkrétních hodnoty ukazovat na různé implementace `col`. Řešení s vtable je obecnější - těch typových parametrů může být více, chování se může v závislosti na nich více lišit.

V jazyce jako Rust nebo C++ tohle není potřeba, protože kompilátor zná dopředu všechny instanciace a provede monomofrizaci, ie. v podstatě z toho udělá různé typy s různými metodami, ale cena za to je, že není možné vytvořit tu hodnotu at runtime.
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.

V tomto případě tam nikde není třeba uchovávat informaci o typu, ani v tagu, ani nikde.

Ale budiž, blbej případ.

Problém není v tom, že by informace nemohla být v runtimu, že by tam nemohl být nějaký tag, nebo co já vím. Ty tvrdíž, že tam být musí, zatímco v Rustu být nemusí. Ale vůbec mi nedochází, kde to musení vidíš.

Představ si lepší překlad:

Kód: [Vybrat]
type Matice a = GenericMatice a | OptimalizedMatice a
let xs : [Matice] = parseFromFile(f)

out = map format xs
where
   format x = case (type x):
      GenericMatice m -> formatGenericMatice m
      OptimalizedMatice m -> formatOptimalizedMatice m

Toto je první příklad, kde by mě napadlo, že by se hodilo type erasured nemít. A určitě se shodnem, že to některé jazyky takto můžou, přidat tam ty tagy, použít. Jiné jazyky něco takové zakážou. A některé jazyky (nebo ty samé, ale prostě si usmysleli) to zoptimalizují tak, že tam budou dvě "uličky" (v tomto případě si to nedokážu úplně představit, ale to není argument - stejně tak nedokážu najít "důkaz", proč by to nemělo jít). Pak tam v rámci optimalizace nebude vůbec žádná informace o typu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 17:35:15
Jazyky jako Idris a Lean (a pár dalších) dělají type erasure a vtables v generovaném kódu taky nepoužívají.
No ano, protože ty hodnoty tagují, jak jsem viděl (v kódu všude velké switche na tagy).

Idris2 se mi instaluje, jak si z něj vygeneruju C kód pomocí 'refc' backendu?
Tagují se součtové typy, to s typovými parametry vůbec nesouvisí.

Dal bych --codegen refc.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 17:37:21
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?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 17:41:08
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.
Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Já té formulaci asi nerozumím.
Tak tak. Ta formulace je blábol, nedává to vůbec smysl.
A byl by nějaký argument? Na co by mi proboha prosím byl vtable, pokud nedělám type erasure? Přesně z toho důvodu, že jazyky jako C++ nebo Rust nedělají type erasure generik (místo toho monomofrigzují) nepotřebují vtables, narozdíl třeba od Javy.
To ale není argument.
Na co by mi v run-time byly typy, když je nepoužívám - proč mít vtable, když jsem typy odrbal = type erasure.
Pokud typy (v run-time) používám, tak neprovedu type erasure, a pak tam ty typy někde musím mít. Třeba jako vtable 1), abych se mohl dotázat, jaký typ má tato hodnota když tu informaci o typu potřebuji.
Situaci, kdy může být uchování typu hodnoty až do runtime zajímavé jsem uváděl v předchozím příspěvku.

Mě přijde, že to chápeš přesně opačně než jak to je :-)


1) Samozřejmě název vtable je zavádějící, protože to se používá v jiném kontextu u C++, ale ty sis začal.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 17:42:15
Tagují se součtové typy, to s typovými parametry vůbec nesouvisí.
Ano, přesně tak, v případě nepoužití vtable je ten typ efektivně konvertován na součtový, tj. v tom příkladu s maticí s prahem velikosti pro jinou reprezentaci to efektivně bude součtový typ obsahující dvě varianty - malá a velká matice.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 17:43:18
Není podstatné, že Lua je dynamický jazyk. Chtěl jsem tím uvést, že když jsem se kouknul do toho zdrojáku, tak tam žádné typové informace, které tvrdíš, že tam musí zůstat aby něco, nebyly.
Jak jsi poznal, že tam nebyly typové informace? V jazyce jako Lua má každá hodnota runtime typovou informaci, tak fungují dynamicky typované jazyky, tzn. ty typy tam nemohly nebýt :)
Na vstupu bylo x = Red. V lue bylo x = 1. To považuji, že tam ten Red není.


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.
Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Dobře, tak mějme ten příklad s maticí. Dejme tomu, že od nějaké velikosti Thr (jako threshold) používá implementace matice nějakou vymakanou reprezentaci v paměti kvůli ušetření místa pro velké matice. Ok? Teď dejme tomu, že máme operaci `col` na matici, která vrátí daný sloupec jako vektor. Tahle operace bude muset fungovat různě v závislosti na Thr, z úsporné reprezentace se čte sloupec jinak než z jednoduché.

Tak, a teď, ty napíšeš program, který načte matici ze souboru a bude chtít číst sloupce. Pokud by ta typová informace - v tomto případě velikost matice - byla komplet odstraněna, metoda `col` by neměla jak poznat, jak je konkrétní matice v paměti reprezentována, a tedy jak extrahovat sloupec. Proto bude muset ta matice si s sebou tu informaci vzít a držet si ji během runtime, buďto to může být nějaký tag, podle kterého udělá ta metoda `col` vidličku, anebo si s sebout vezme vtable, která bude u různých konkrétních hodnoty ukazovat na různé implementace `col`. Řešení s vtable je obecnější - těch typových parametrů může být více, chování se může v závislosti na nich více lišit.

V jazyce jako Rust nebo C++ tohle není potřeba, protože kompilátor zná dopředu všechny instanciace a provede monomofrizaci, ie. v podstatě z toho udělá různé typy s různými metodami, ale cena za to je, že není možné vytvořit tu hodnotu at runtime.
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.

V tomto případě tam nikde není třeba uchovávat informaci o typu, ani v tagu, ani nikde.

Ale budiž, blbej případ.

Problém není v tom, že by informace nemohla být v runtimu, že by tam nemohl být nějaký tag, nebo co já vím. Ty tvrdíž, že tam být musí, zatímco v Rustu být nemusí. Ale vůbec mi nedochází, kde to musení vidíš.

Představ si lepší překlad:

Kód: [Vybrat]
type Matice a = GenericMatice a | OptimalizedMatice a
let xs : [Matice] = parseFromFile(f)

out = map format xs
where
   format x = case (type x):
      GenericMatice m -> formatGenericMatice m
      OptimalizedMatice m -> formatOptimalizedMatice m

Toto je první příklad, kde by mě napadlo, že by se hodilo type erasured nemít. A určitě se shodnem, že to některé jazyky takto můžou, přidat tam ty tagy, použít. Jiné jazyky něco takové zakážou. A některé jazyky (nebo ty samé, ale prostě si usmysleli) to zoptimalizují tak, že tam budou dvě "uličky" (v tomto případě si to nedokážu úplně představit, ale to není argument - stejně tak nedokážu najít "důkaz", proč by to nemělo jít). Pak tam v rámci optimalizace nebude vůbec žádná informace o typu.
Informace o typu tam nebude nikdy. Idris a spol. mají kvantitativní typový systém a tzv. implicitní argumenty. To jsme ale hodně odbočili. Jinak pro ten příklad s maticí by se asi použil typ LTE, není nutné psát součtový typ, to je boilerplate. Ale jak říkám, to jsme odbočili k úplně jinému tématu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 17:44:45
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?
Nechcete si to psát přímo v kódu? Třeba tady: https://learn-idris.net/play
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 17:46:48
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 17:47:00
Tagují se součtové typy, to s typovými parametry vůbec nesouvisí.
Ano, přesně tak, v případě nepoužití vtable je ten typ efektivně konvertován na součtový, tj. v tom příkladu s maticí s prahem velikosti pro jinou reprezentaci to efektivně bude součtový typ obsahující dvě varianty - malá a velká matice.
Ne, nebude (pokud se pořád bavíme o Idrisu/Leanu).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 17:48:22
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 17:50:11
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 17:52:10
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 17:54:28
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 17:55:36
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 18:07:01
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č.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 18:08:13
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 18:14:16
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
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 18:15:08
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 18:17:03
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?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 18:18:50
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 18:21:13
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ě. 1)



1) Ignorujeme skutečnost, že Java bude brutálně optimalizovat, a JITovat, takže ve skutečnosti ten kód bude všelijakej.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 18:27:01
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 05. 12. 2022, 18:32:02
1) 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.)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 18:36:12
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 18:36:48
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.
Domnívám se, že to zajímavé je, protože Nat je součtový typ, takže to je, jako kdyby ten typový parametr byl enum (je to diskrétní typ se dvěma konstruktory). Kdyby to byl Int, bylo by možných hodnot nekonečně mnoho.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 18:49:08
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.
Domnívám se, že to zajímavé je, protože Nat je součtový typ, takže to je, jako kdyby ten typový parametr byl enum (je to diskrétní typ se dvěma konstruktory). Kdyby to byl Int, bylo by možných hodnot nekonečně mnoho.

Rozumím. Důsledky mi dochází. Děkuji. Můžem pokračovat.

Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 18:52:24
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.
Domnívám se, že to zajímavé je, protože Nat je součtový typ, takže to je, jako kdyby ten typový parametr byl enum (je to diskrétní typ se dvěma konstruktory). Kdyby to byl Int, bylo by možných hodnot nekonečně mnoho.
Rozumím. Důsledky mi dochází. Děkuji. Můžem pokračovat.
Fajn. Takže ten první konstruktor, řekněme ZIsEven, je typu IsEven 0. To je zřejmé, ne?

A ten druhý konstruktor má argument typu IsEven, jeho typ je
Kód: [Vybrat]
SuccSuccIsEven : IsEven n -> IsEven (n+2)
Jasné zatím? Otázky?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 19:07:33
Fajn. Takže ten první konstruktor, řekněme ZIsEven, je typu IsEven 0. To je zřejmé, ne?

A ten druhý konstruktor má argument typu IsEven, jeho typ je
Kód: [Vybrat]
SuccSuccIsEven : IsEven n -> IsEven (n+2)
Jasné zatím? Otázky?

Jasné. Chápu-li to správně, tak se to samozřejmě bude chovat rekurzivně, etc. Tak?

Komplet zápis takto?
Kód: [Vybrat]
data IsEven : Nat -> Type where
    ZIsEven  : IsEven 0
    SuccSuccIsEven : IsEven n -> IsEven (n+2)

Říkáš, že Nat je Součtový (diskrétní) typ, takže tam nemůže být nekonečně mnoho čísel. Takže je nějak definováno něco jako NatMax, NatMin? Tedy mohu klidně používat normálně Int, protože stejně ten Int není nekonečnej, ale nějakej automaticky zvětšující Number už bych použít nemohl... Tak?

Ten Type je zadrátovaný klíčový slovo/typ?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 19:23:33
Kód: [Vybrat]
SuccSuccIsEven : IsEven n -> IsEven (n+2)
Jasné zatím? Otázky?
Jasné. Chápu-li to správně, tak se to samozřejmě bude chovat rekurzivně, etc. Tak?
Jo, tento konstruktor je rekurzivní.

Komplet zápis takto?
Kód: [Vybrat]
data IsEven : Nat -> Type where
    ZIsEven  : IsEven 0
    SuccSuccIsEven : IsEven n -> IsEven (n+2)
Ano.

Říkáš, že Nat je Součtový (diskrétní) typ, takže tam nemůže být nekonečně mnoho čísel. Takže je nějak definováno něco jako NatMax, NatMin?
Nejmenší hodnota je nula, ale jinak to omezené není, těch hodnot je nekonečně (spočetně) mnoho, právě díky rekurzi toho druhého konstruktoru.

Ten Type je zadrátovaný klíčový slovo/typ?
Jo, ten je zvláštní, protože typů pro typy by mělo být nekonečně mnoho (aby nedošlo k něčemu na způsob Russellova paradoxu), jenže zrovna Idris si tu typovou úroveň odvodí sám. Například Lean ji potřebuje explicitně. Nicméně pro naše příklady to není podstatné, je to prostě zabudovaný typ (a slouží také k deklaraci HKT).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 19:28:13
Říkáš, že Nat je Součtový (diskrétní) typ, takže tam nemůže být nekonečně mnoho čísel. Takže je nějak definováno něco jako NatMax, NatMin?
Nejmenší hodnota je nula, ale jinak to omezené není, těch hodnot je nekonečně (spočetně) mnoho, právě díky rekurzi toho druhého konstruktoru.

eee, tak je ten Nat diskrétní, nebo ne? :-)

Chápu to s tou rekurzí. Nechápu proč je podstatné, že Nat je diskrétní, když pak tvrdíš, že není  :o
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 19:32:31
Říkáš, že Nat je Součtový (diskrétní) typ, takže tam nemůže být nekonečně mnoho čísel. Takže je nějak definováno něco jako NatMax, NatMin?
Nejmenší hodnota je nula, ale jinak to omezené není, těch hodnot je nekonečně (spočetně) mnoho, právě díky rekurzi toho druhého konstruktoru.
eee, tak je ten Nat diskrétní, nebo ne? :-)

Chápu to s tou rekurzí. Nechápu proč je podstatné, že Nat je diskrétní, když pak tvrdíš, že není  :o
Jistěže je diskrétní (a také konečný), má jen dva konstruktory, nulu (Z) a následníka (S). Jenže ten druhý je rekurzivní, libovolné přirozené číslo n se vyjádří jako SnZ. Takže hodnot je nekonečně mnoho. Je to takto zřejmé?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Wavelet 05. 12. 2022, 19:35:32
Říkáš, že Nat je Součtový (diskrétní) typ, takže tam nemůže být nekonečně mnoho čísel. Takže je nějak definováno něco jako NatMax, NatMin?
Nejmenší hodnota je nula, ale jinak to omezené není, těch hodnot je nekonečně (spočetně) mnoho, právě díky rekurzi toho druhého konstruktoru.
eee, tak je ten Nat diskrétní, nebo ne? :-)

Chápu to s tou rekurzí. Nechápu proč je podstatné, že Nat je diskrétní, když pak tvrdíš, že není  :o
Jistěže je diskrétní (a také konečný), má jen dva konstruktory, nulu (Z) a následníka (S). Jenže ten druhý je rekurzivní, libovolné přirozené číslo n se vyjádří jako SnZ. Takže hodnot je nekonečně mnoho. Je to takto zřejmé?

Typoonanismus
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 05. 12. 2022, 19:40:26
Jistěže je diskrétní (a také konečný), má jen dva konstruktory, nulu (Z) a následníka (S). Jenže ten druhý je rekurzivní, libovolné přirozené číslo n se vyjádří jako SnZ. Takže hodnot je nekonečně mnoho. Je to takto zřejmé?

Ano je.

Takže na místo Haskellovského
Kód: [Vybrat]
data Nat = 0,1,..., NatMax
je tam definice

Kód: [Vybrat]
data Nat : where
    Z  : Nat 0
    Succ : Nat n -> Nat (n+1)
nebo něco takového.

Haskell má Number jako buildin rozsah čísla. Zatímco Idris to má definováno vzorečkem.

Asi se chytám.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 05. 12. 2022, 19:45:49
Jistěže je diskrétní (a také konečný), má jen dva konstruktory, nulu (Z) a následníka (S). Jenže ten druhý je rekurzivní, libovolné přirozené číslo n se vyjádří jako SnZ. Takže hodnot je nekonečně mnoho. Je to takto zřejmé?
je tam definice
Kód: [Vybrat]
data Nat : where
    Z  : Nat 0
    Succ : Nat n -> Nat (n+1)
nebo něco takového.
Ano, akorát bez těch typových parametrů. Takto to mají všechny funkcionální jazyky, i třeba OCaml. Prostě Peanova definice :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 06. 12. 2022, 00:47:59
Jestli už máš Idris 2, tak můžeš zkusit tohle:
Kód: [Vybrat]
...
Zkusil jsem. Ten generovaný C kód je naivní interpreter, optimalizace veškeré žádné, každá hodnota by default alokována a reference counted ... nevidím nic o cyklech nebo weak referencích, cykly buď není možné vytvořit, nebo leakují... Reference couting není atomický... I třeba sečtení dvou čísel je alokace nové hodnoty, vždy... Ten typový parametr rozměru se tam prostě zpropaguje jak v C tak i v JS kódu, žádný type-erasure, neměl jsem na ten výrok o type-erasure v první řadě vůbec skočit.

Ááááchjo.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 04:53:00
Ten typový parametr rozměru se tam prostě zpropaguje jak v C tak i v JS kódu, žádný type-erasure, neměl jsem na ten výrok o type-erasure v první řadě vůbec skočit.
Jak zněl ten výrok?
Co z této tvé zkušenosti vyplývá?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 05:55:11
Co z této tvé zkušenosti vyplývá?
Že Králík neví, co je interpretr ::) Ale aspoň už zjistil, co jsou v Idrisu implicitní parametry.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 06. 12. 2022, 09:19:42
Ten typový parametr rozměru se tam prostě zpropaguje jak v C tak i v JS kódu, žádný type-erasure, neměl jsem na ten výrok o type-erasure v první řadě vůbec skočit.
Jak zněl ten výrok?
->
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í. Například Idris nebo Lean umí transpilaci do C, kde není runtime pro typy ani GC, veškerou kontrolu oddře překladač a když usoudí, že je kód typově správně, vyplivne výstup bez typových parametrů, ty právě slouží pouze ke statické kontrole.

JS kód vygenerovaný Idrisem:

Kód: [Vybrat]
function Main_getCol($0, $1, $2) {
 const $3 = Data_Nat_isLTE($0, 1000n);
 switch($3.h) {
  case 0: /* Yes */ return Main_getCol1($1, $2);
  default: return Main_getCol2($1, $2);
 }
}

$0 je velikost matice.

V Céčku je kód cca to samý, akorát mnohem výřečnější, protože úplně všechny hodnoty (i funkce) jsou boxovány do typu Value, které pak ten rozhodně-ne-interpretr, no, jaksi interpretuje :D

---

Že Králík neví, co je interpretr ::) Ale aspoň už zjistil, co jsou v Idrisu implicitní parametry.
::)

Především jsem zjistil, že si strašně vymýšlíš. Také jsem zjistil, že Idris je jen jakési experimentální skriptovadlo - měl jsem dříve představu, že to je kompilovaný jazyk jako Haskell.

Btw. v této přednášce (https://youtu.be/t0mhvd3-60Y?t=2843) Simon Peyton Jones mluví o možnostech linearity v Haskellu a také trochu o Rustu, borrowing/ownership označuje jako "Linearity on the Kinds". Asi by to chtělo mu dát vědět, že to má špatně, že uživatel Idris prohlásil, že borrowing/ownership nemá s typovým systémem vůbec nic společného...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 09:42:52
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 je ovšem tvůj problém, nikdo to tady netvrdil. Naopak ti bylo řečeno, že má různé backendy (C, JS, ...). Defaultně používá Scheme (Chez).

Btw. v této přednášce (https://youtu.be/t0mhvd3-60Y?t=2843) Simon Peyton Jones mluví o možnostech linearity v Haskellu a také trochu o Rustu, borrowing/ownership označuje jako "Linearity on the Kinds".
Ale to je velmi trefné, 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, ale v kombinaci s ním (v Rustu jde zejména o reference, to asi víš, co je) zaručuje paměťovou bezpečnost. BoneFlute ti to možná vysvětlí, má s tebou evidentně větší trpělivost ;)

P.S. Máš malé nevýznamné plus za ten odkaz :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 09:45:33
Fajn. Takže ten první konstruktor, řekněme ZIsEven, je typu IsEven 0. To je zřejmé, ne?

A ten druhý konstruktor má argument typu IsEven, jeho typ je
Kód: [Vybrat]
SuccSuccIsEven : IsEven n -> IsEven (n+2)
Jasné zatím? Otázky?

Jasné. Chápu-li to správně, tak se to samozřejmě bude chovat rekurzivně, etc. Tak?

Komplet zápis takto?
Kód: [Vybrat]
data IsEven : Nat -> Type where
    ZIsEven  : IsEven 0
    SuccSuccIsEven : IsEven n -> IsEven (n+2)

Říkáš, že Nat je Součtový (diskrétní) typ, takže tam nemůže být nekonečně mnoho čísel. Takže je nějak definováno něco jako NatMax, NatMin? Tedy mohu klidně používat normálně Int, protože stejně ten Int není nekonečnej, ale nějakej automaticky zvětšující Number už bych použít nemohl... Tak?

Ten Type je zadrátovaný klíčový slovo/typ?
Chceš na to ještě nějak navázat? Otázky k tomuto konkrétnímu příkladu?
Pokud ne, možná by tě ještě zajímaly implicitní parametry v kvantitativních typových systémech (které teď s velkou slávou objevil Králík)?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 09:48:14
si strašně vymýšlíš
Aha. Tak nám v tom transpilovaném kódu ukaž, kde jsou ty tvoje runtimy, GC a vtables, o kterýchs tvrdil, že tam určitě musí být. Kampak se nám ty čerchmanti schovali? Neznáš pořádně ani Rust, natož GADT, ale myslím, že už ses z této diskuse dost naučil (díky, BoneFlute) a klidně můžeme ještě nějakou dobu pokračovat ;)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 06. 12. 2022, 10:06:35
Aha. Tak nám v tom transpilovaném kódu ukaž, kde jsou ty tvoje runtimy, GC a vtables, o kterýchs tvrdil, že tam určitě musí být.
Runtime v tom C kódu pochopitelně je velmi silně. GC tam je, byť v primitivní formě - refcounting všeho. V JS a Java výstupu pochopitelně implicitně jsou GC i silný runtime. Vtables tam (v C) nejsou a ani dispatch na základě typových tagů - tohle jsem předpokládal na základě tvého nepravdivého výroku, že typové parametry jsou vymazány a vůbec ve výsledném kódu nefigurují - pokud tam typový parametr může zůstat, není pro tyto mechanismy důvod (alespoň v tomto příkladu - neznám všechny zákoutí toho jazyka). Takhle stačí?

ale myslím, že už ses z této diskuse dost naučil (díky, BoneFlute) a klidně můžeme ještě nějakou dobu pokračovat ;)
Od BoneFlute by ses měl učit především ty.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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 :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 10:18:26
Aha. Tak nám v tom transpilovaném kódu ukaž, kde jsou ty tvoje runtimy, GC a vtables, o kterýchs tvrdil, že tam určitě musí být.
Runtime v tom C kódu pochopitelně je velmi silně. GC tam je, byť v primitivní formě
Runtime tam žádný není. Ukaž nám, co tam je podle tebe runtime. GC je pro hodnoty, tys tvrdil, že se tam boxují, alokují a uvolňují typové parametry. To tam taky není.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 10:20:36
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
Tak jsme se konečně shodli, není součástí, ale je provázaná. Můžeme slavit :)

P.S. Jako bonus je tady odkaz na zmíněný seriál o Mercury, někde se tam probírají lineární typy a také IO ve funkcionálním paradigmatu (spoiler: není to tam jako v Haskellu): https://www.root.cz/serialy/mercury/
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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 :D 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?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Martin Sivák 06. 12. 2022, 10:27:06
Popravdě mám dojem, že se v té teorii typů dost vyžíváte a děláte jí spíš medvědí službu.

Ano, indukční definice typu sudá čísla je pěkná ukázka. A v dalším kódu už pak opravdu můžeme mít jenom krásné garantované sudé číslo a optimalizátor tu informaci může pěkně využít.

Jenže co se stane, když načtete uživatelský vstup a bude tam číslo liché? Nějaký implicitní nebo explicitní parser musí rozhodnout, jestli ta hodnota je v pořádku nebo není a nějak zareagovat. A to je část, co se z ukázek síly funkcionálního programování typicky vypouští.

Vysokoúrovňové informace pro optimalizátor nejsou navíc nezbytně omezeny jen na funkcionální jazyky. Ada a Eiffel mají třeba design by contract (= vstupní podmínky pro parametry), ostatní jazyky budou mít nějaký interface pro next, stream, iterátory nebo cokoliv podobného. (Lazy generátor v Haskellu interně stejně nic jiného nedělá). Dneska s LLVM a LTO se navíc optimalizace často dělají až nad mezikódem.

Pokud se budeme bavit o generických maticích, tak tu informaci o velikosti si to samozřejmě musí nést s sebou, pokud není známá v době překladu. VTable tam být nemusí, protože matice jsou specializovaný případ a stačí číslo. Maximálně, kdyby to bylo tak chytré, že pro některé operace nad specifickými velikostmi použije speciální extrémně optimalizovanou implementaci. Ale opět, v runtime jde o vstup od uživatele, takže tam musí být parser, error handling a nějaký dynamický dispatch.

Pokud by vstupem od uživatele byl samotný typ i s hodnotou (řekněme program "kompot", který správně odpeckuje, pomele, vyrobí etiketu podle počtu a typu vstupního ovoce), tak to interně samozřejmě dynamický dispatch mít bude. Jednoduše pro to, že každé to ovoce (Typ) se zpracovává jinak a náš abstraktní turingův stroj (CPU) neumí nic jiného než skoky dle adres, které si někde přečte.

Procesor s matematickou indukcí ještě nikdo nenapsal a z hlediska strojového kódu to nakonec vždy skončí procedurálně, takže výhoda a nevýhoda těchto jazyků je hlavně ve formální analýze během překladu. Ale ta se dá podpořit i jinak.


Co se typů v Rustu týče, tak borrow checker je move sémantika + escape analysis. Ale lifetime specifier je jednoznačně součást definovaného typu a poskytuje borrow checkeru informace navíc (= něco dle designu musí žít déle než něco jiného). Tuto informaci čistě z kódu neodvodíte, protože algoritmus co tam vývojář napíše, může být z hlediska požadavků typu špatně.

Lifetime pro dokázání správnosti nakládání s pamětí teoreticky nepotřebujete, pokud životnost hlídá jiný mechanizmus jako ref count nebo GC. Ale to má zase runtime implikace.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 06. 12. 2022, 10:33:34
Runtime tam žádný není.
:D Promiň, ale tohle už je opravdu hodně absurdní. Tak se podívej do zdrojáku (https://github.com/idris-lang/Idris2/tree/main/support/refc), 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...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 10:35:17
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
Jsou to typové parametry a ta funkce je generická, takže ano, jsou součástí typu funkce. Ovšem o move vs. borrow rozhoduje, jestli je typ reference (to andítko je jiný typový konstruktor nesouvisející s lifetimy). A borrow checker kontroluje, že reference jsou vždy platné tam, kde se používají (escape analýza). Taky že jsou unikátní v případě mut, ale takových detailů tam je hodně. 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), 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).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 10:39:16
Viděl jsi ten kód vůbec někdy?
Viděl, i když většinou jsem potřeboval JS.
Nicméně ptám se na runtime zachazející s těmi typovými parametry, o kterém jsi tvrdil, že je nutný. Že tam je funkce na počítání referencí by tě nemělo překvapovat, kde jsi použil backend nazvaný “ref-counting C” :D
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 10:44:54
Jenže co se stane, když načtete uživatelský vstup a bude tam číslo liché?
Použije se funkce vracející hodnotu typu Dec (IsEven n), který je součástí standardní knihovny a implementuje rozhodnutelnost (nějaké vlastnosti, v tomto případě sudosti). To je součtový typ “zabalující” buď hodnotu typu IsEven n nebo Not (IsEven n). Myslím, že k tomu ta diskuse směřovala a pokud bude mít BoneFlute zájem, určitě dojde i na příklady.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 10:47:32
Co se typů v Rustu týče, tak borrow checker je move sémantika + escape analysis. Ale lifetime specifier je jednoznačně součást definovaného typu a poskytuje borrow checkeru informace navíc
Přesně tak.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 10:50:17
veškeré obecné možnosti HTKs a GADTs, zejména v situaci, kdy hraje roli dynamický vstup
No a vidíš, že v Idrisu, Leanu, Agdě, Coqu (a OCamlu, Scale…) pro to žádné vtables nepotřebuješ.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 06. 12. 2022, 10:59:35
Citace
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 11:05:41
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ý"?
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.

Reference ostatně mají téměř všechny mainstreamové jazyky a lifetimy jsou implicitně v každém překladači provádějícím escape analýzu. Více či méně chytrý je ovšem ten algoritmus escape analýzy (Java nic moc, Go lepší, ale dost věcí mu unikne, Rust propracovaný).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 11:09:10
bylo by možné to opravdu udělat bez runtime prostě zpropagováním toho parametru jako běžného parametru funkce.
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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Martin Sivák 06. 12. 2022, 11:41:13
Reference ostatně mají téměř všechny mainstreamové jazyky a lifetimy jsou implicitně v každém překladači provádějícím escape analýzu.

Implicitní ano, každý překladač si hlídá co kde má a jestli to ještě žije. Jenže u referencí to nejde. Objekt na který reference ukazuje může teoreticky žít nekonečně dlouho a nebo taky ne. Takže se používá buď runtime RC, GC nebo statické lifetimes. Případně immutable sémantika z hlediska jazyka, ale ta také interně tu paměť musí uvolňovat, protože prakticky nemáme neomezené množství..
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 11:43:46
parametr tam můžeme zpropagovat, pokud to potřebujeme, pomocí této fíčury ('implicit arguments')
Je rozdíl mezi type erasure a type parameter erasure ;)
Ale už to uzavřeme, myslím, že teď už je všem jasné, jak to funguje. V čem má smysl pokračovat je ten příklad s GADT pro IsEven. Tam bude zajímavější i ten vygenerovaný kód, protože s typem Nat se pojí zajímavé optimalizace.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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í...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 12:00:08
Tam bude zajímavější i ten vygenerovaný kód, protože s typem Nat se pojí zajímavé optimalizace.
Hořím zvědavostí...
Však si to přelož.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: snugar_i 06. 12. 2022, 12:08:38
@Králík: Obdivuju tvoji trpělivost...
@Idris: S tímhle přístupem "udělám ze všech debily" moc nových zájemců o funkcionální programování asi nevytvoříš - co přesně je tvůj cíl?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 06. 12. 2022, 14:59:49
Ještě pro zajímavost přidám odkaz na jazyk Carp (https://github.com/carp-lang/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 (https://github.com/carp-lang/Carp/blob/master/docs/Memory.md) 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".
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 15:18:56
Na stránce o memory managementu (https://github.com/carp-lang/Carp/blob/master/docs/Memory.md) mají hezkou ukázku, jak move semantics v jazyce bez GC potřebují od typového systému
Jako v Mercury. Jo, mít u typů multiplicitu se hodí.

Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 15:35:59
Ten typový parametr rozměru se tam prostě zpropaguje jak v C tak i v JS kódu, žádný type-erasure, neměl jsem na ten výrok o type-erasure v první řadě vůbec skočit.
Jak zněl ten výrok?
->
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í. Například Idris nebo Lean umí transpilaci do C, kde není runtime pro typy ani GC, veškerou kontrolu oddře překladač a když usoudí, že je kód typově správně, vyplivne výstup bez typových parametrů, ty právě slouží pouze ke statické kontrole.

JS kód vygenerovaný Idrisem:

Kód: [Vybrat]
function Main_getCol($0, $1, $2) {
 const $3 = Data_Nat_isLTE($0, 1000n);
 switch($3.h) {
  case 0: /* Yes */ return Main_getCol1($1, $2);
  default: return Main_getCol2($1, $2);
 }
}

$0 je velikost matice.

V Céčku je kód cca to samý, akorát mnohem výřečnější, protože úplně všechny hodnoty (i funkce) jsou boxovány do typu Value, které pak ten rozhodně-ne-interpretr, no, jaksi interpretuje :D

Tak buďme na Idrise krutí, a řekněme, že to nebylo úplně nejlépe formulováno. Ale:

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?

1/ Cítím určitý rozdíl mezi tím, když Python nebo Java jakožto dynamický jazyk narve spousta kontrol do runtime, protože nemá instrumenty na to, jak jinak. A mezi tím, že Idris by spousta typů do výsledného zdrojáku dávat nemusel, protože ty instrumenty má, ale také je ve verzi v0.6.0, a na optimalizace kašle.

2/ Také vidím určitý rozdíl mezi tím, když Idris při kompilaci oznámí, že kód je nekorektní, zatímco Java/Python by to oznámila až v runtime - a mezi tím, že Idris neprovádí optimalizace.

Jak jsem uváděl příklad s Amuletem, tam jsem se bavil tím, že opravdu optimalizoval. Z toho jsem čerpal já. Takže jsem pochopil, že to jde.

Pokud bylo tvým cílem dokázat, že Idris (jazyk) má před sebou ještě dlouhou cestu, protože neoptimalizuje kód jak by mohl - ok, máš boda.

Pokud bylo tvým cílem vysvětlit co je to type erasure, nebo jak probíhá optimalizace, nebo jaké jsou možnosti silných statických jazyků - tak to se ti nepovedlo.

Pokud bylo tvým cílem vysvětlit, že Rust je předvídatelnější (časově, paměťově) než Idris - ok, s tím nemám problém.

Dále jsem se ztratil v tom, co jsi chtěl vlastně dokazovat, promiň :-)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 15:50:25
Popravdě mám dojem, že se v té teorii typů dost vyžíváte a děláte jí spíš medvědí službu.

Ano, indukční definice typu sudá čísla je pěkná ukázka. A v dalším kódu už pak opravdu můžeme mít jenom krásné garantované sudé číslo a optimalizátor tu informaci může pěkně využít.

Jenže co se stane, když načtete uživatelský vstup a bude tam číslo liché? Nějaký implicitní nebo explicitní parser musí rozhodnout, jestli ta hodnota je v pořádku nebo není a nějak zareagovat. A to je část, co se z ukázek síly funkcionálního programování typicky vypouští.
Naopak!
To je na tom právě to kouzelné, že staticky typované jazyky tě přinutí, aby si zohlednil situaci když je to číslo liché. To je právě ta smetana, po které toužíme. Garance.

Vysokoúrovňové informace pro optimalizátor nejsou navíc nezbytně omezeny jen na funkcionální jazyky. Ada a Eiffel mají třeba design by contract (= vstupní podmínky pro parametry), ostatní jazyky budou mít nějaký interface pro next, stream, iterátory nebo cokoliv podobného. (Lazy generátor v Haskellu interně stejně nic jiného nedělá). Dneska s LLVM a LTO se navíc optimalizace často dělají až nad mezikódem.
compile time?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 15:54:01
Ano, indukční definice typu sudá čísla je pěkná ukázka. A v dalším kódu už pak opravdu můžeme mít jenom krásné garantované sudé číslo a optimalizátor tu informaci může pěkně využít.

Jenže co se stane, když načtete uživatelský vstup a bude tam číslo liché? Nějaký implicitní nebo explicitní parser musí rozhodnout, jestli ta hodnota je v pořádku nebo není a nějak zareagovat. A to je část, co se z ukázek síly funkcionálního programování typicky vypouští.
Naopak!
To je na tom právě to kouzelné, že staticky typované jazyky tě přinutí, aby si zohlednil situaci když je to číslo liché. To je právě ta smetana, po které toužíme. Garance.
Přesně tak.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 16:03:29
ž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

Nevím jak Idris, ale já se snažil vždycky psát, že ty typové informace se vymažou (můžou vymazat), když nejsou potřeba. A když jsou potřeba, tak je samozřejmě třeba je neodstraňovat. Dokonce jsem na to psal kód, aby mi bylo dobře rozumět. Jaký zmatek je v tomto bodě?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 16:05:55
Chceš na to ještě nějak navázat? Otázky k tomuto konkrétnímu příkladu?
Určitě ano, ale nyní mám povinnosti.
Večer.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 16:23:52
já se snažil vždycky psát, že ty typové informace se vymažou (můžou vymazat), když nejsou potřeba. A když jsou potřeba, tak je samozřejmě třeba je neodstraňovat
Ono to je matoucí, protože k type erasure dochází vždy (v tom smyslu, že tam není žádný reifikovaný typ Vect nebo Matrix, tj. instance neví, jakého jsou typu), ale používané typové parametry se předávají přímo funkcím, které je potřebují.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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ý :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 16:43:02
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.

Dobře. Zkusme se na to podívat z nového směru.

Nejdřív úvod: Máme compile-time (Haskell, Idris, Rust) a run-time jazyky (Java, Python, JS, Lua).
A můžeme posuzovat kritéria:
- rychlost běhu
- předvídatelnost
- čitelnost
- garance

A teď se pojďme bavit o čitelnosti a garancích. Run-time jazyky neposkytují vůbec žádné záruky. To je věřím jasná věc.

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ší?

2/ Kde jsou hranice záruk, které poskytuje Rust, ale Idris je ještě je schopen poskytnout?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 17:17:02
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, ...
Argumentace C/C++ je varianta Godwinova zákona.


2/ Kde jsou hranice záruk, které poskytuje Rust, ale Idris je ještě je schopen poskytnout?
Tady asi nerozumim otázce...
Rust je schopen zajistit, že nedojde k memory leaku.
Rust je schopen zajistit, že nedojde k race-condition.
A určitě umí další věci.
Je schopen Rust vynutit, aby programátor zkontroloval, že tady a tady bylo pouze sudé číslo? Idris to umí.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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í.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 19:24:01
Chceš na to ještě nějak navázat? Otázky k tomuto konkrétnímu příkladu?
Určitě ano, ale nyní mám povinnosti.
Večer.
Teď mě napadlo, jak jsi zmiňoval to tehdejší forall, že existenční typy jdou vyjádřit jednodušeji pomocí GADT.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 21:31:07
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áš...
Rust běžící v prohlížeči ti také neumožní smazat $HOME. JS běžící z příkazové řádky ti $HOME smaže klidně.



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í.
OK, doplním zadání:

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

Rust je schopen zajistit, že nedojde k memory leaku. Idris také.
Rust je schopen zajistit, že nedojde k race-condition. Idris také.
Rust je schopen zajistit, že že string bude vždy utf8-korektní. Idris také.
A určitě umí další věci.
Je schopen Rust vynutit, aby programátor zkontroloval, že tady a tady bylo pouze sudé číslo? Idris to umí.
Je schopen Rust vunutit, aby text byl neprázdný? Haskell to umí 1).


1) https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 21:49:31
Je schopen Rust vunutit, aby text byl neprázdný? Haskell to umí
A Idris to umí ještě lépe, nemusíš kvůli tomu definovat nový typ ;)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 22:38:11
Je schopen Rust vunutit, aby text byl neprázdný? Haskell to umí
A Idris to umí ještě lépe, nemusíš kvůli tomu definovat nový typ ;)

Teď jsem ve fázi, zda. Jak je jiná otázka.

Třeba to forall mi přišlo poněkud složité oproti přímočarým rozhraním v průmyslových jazycích. Ale je fakt, že to nemám v krvi a mé seznámení s ním bylo jen zběžné, a tak to neumím docenit. Asi to umí víc, nebo to nějak elegantněji zapadá, co já vím.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 06. 12. 2022, 22:44:27
Třeba to forall mi přišlo poněkud složité oproti přímočarým rozhraním v průmyslových jazycích.
Ono je složitější, protože typové třídy mají typový parametr, kdežto rozhraní v Javě nebo Go ho mít nemusí. Jsou to rozdílné věci. Ale jak jsem psal, forall se dá zbavit použitím GADT.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 23:40:05
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.

Nehledej v tom žádný podraz ani žádnou složitost. Čti přesně co píšu.

Rust poskytuje záruky. Proto ho mám rád.
Haskell, Idris, etc - poskytují záruky.

Rust u některých věcí není schopen záruky poskytnout. Neumí to.
Java není schopna zaručit, že přeložený kód nepadne na NullException.
Haskell není schopen zaručit... - já nevím, určitě tam něco bude, ale jsem línej to vymejšlet.

Java je méně schopná jak Rust, Rust je méně schopnej jak Haskell (asi - neber mě za slovo).

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

Umí Java vynutit, aby v kódu nenastala situace, že na místě kde je potřeba neprázdný string se objevil prázdný string? Odpověď: ani za zlatý prase.
Umí Java zajistit, aby v kódu nenastala situace, že na místě, kde je třeba sudé číslo přišlo číslo liché? Odpověď: LOL.

Co Rust? Hodně toho umí. Co už neumí? Kde cca stojí ta hranice?

btw: To, že Rust některé záruky nedokáže zajistit je fakt, nikoliv hendikep. I tak je to zjevení, a jsem nadšen, že existuje.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 23:48:04
Chceš na to ještě nějak navázat? Otázky k tomuto konkrétnímu příkladu?

Kód: [Vybrat]
data IsEven : Nat -> Type where
    ZIsEven  : IsEven 0
    SuccSuccIsEven : IsEven n -> IsEven (n+2)


sumx : IsEven -> IsEven -> IsEven
-- sumx : Int -> Int -> Int
sumx x y = x * y


main : IO ()
main = putStrLn $ "Hello: " ++ (show (sumx 2 4))

Ještě mi něco schází vědět?: "Mismatch between: Nat -> Type and Type."
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 06. 12. 2022, 23:54:00
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.

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)  ;D
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 00:08:45
Kód: [Vybrat]
data IsEven : Nat -> Type where
    ZIsEven  : IsEven 0
    SuccSuccIsEven : IsEven n -> IsEven (n+2)

sumx : IsEven -> IsEven -> IsEven
-- sumx : Int -> Int -> Int
sumx x y = x * y

main : IO ()
main = putStrLn $ "Hello: " ++ (show (sumx 2 4))
Ještě mi něco schází vědět?: "Mismatch between: Nat -> Type and Type."
IsEven musí mít typový parametr. A je to jen kontrakt, že ten parametr je sudé číslo. Nějak takto to bude fungovat:
Kód: [Vybrat]
data IsEven : Nat -> Type where
    ZIsEven  : IsEven 0
    SuccSuccIsEven : IsEven n -> IsEven (2+n)

sumx : (n : Nat) -> {auto 0 prf1 : IsEven n} -> (m : Nat) -> {auto 0 prf2 : IsEven m} -> Nat
sumx n m = n + m
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 00:32:53
IsEven musí mít typový parametr. A je to jen kontrakt, že ten parametr je sudé číslo. Nějak takto to bude fungovat:
Kód: [Vybrat]
data IsEven : Nat -> Type where
    ZIsEven  : IsEven 0
    SuccSuccIsEven : IsEven n -> IsEven (2+n)

sumx : (n : Nat) -> {auto 0 prf1 : IsEven n} -> (m : Nat) -> {auto 0 prf2 : IsEven m} -> Nat
sumx n m = n + m

No tak to je teda hnusný zápis  :P :) Pak mi musíš vysvětlit, proč to tam je.

Bohužel: "Can't find an implementation for IsEven 2."

Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 00:40:28
IsEven musí mít typový parametr. A je to jen kontrakt, že ten parametr je sudé číslo. Nějak takto to bude fungovat:
Kód: [Vybrat]
data IsEven : Nat -> Type where
    ZIsEven  : IsEven 0
    SuccSuccIsEven : IsEven n -> IsEven (2+n)

sumx : (n : Nat) -> {auto 0 prf1 : IsEven n} -> (m : Nat) -> {auto 0 prf2 : IsEven m} -> Nat
sumx n m = n + m
No tak to je teda hnusný zápis  :P :) Pak mi musíš vysvětlit, proč to tam je.

Bohužel: "Can't find an implementation for IsEven 2."
Jakou máš verzi Idrisu? Funguje to v 0.6.0.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 00:47:33
Co znamená ta 0 mezi `auto` a jménem implicitního argumentu?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 00:50:31
Co znamená ta 0 mezi `auto` a jménem implicitního argumentu?
To je multiplicita (viz kvantitativní typový systém). Nula znamená erasure :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 00:56:06
Co znamená ta 0 mezi `auto` a jménem implicitního argumentu?
https://idris2.readthedocs.io/en/latest/tutorial/multiplicities.html
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 01:00:35
IsEven musí mít typový parametr. A je to jen kontrakt, že ten parametr je sudé číslo. Nějak takto to bude fungovat:
Kód: [Vybrat]
data IsEven : Nat -> Type where
    ZIsEven  : IsEven 0
    SuccSuccIsEven : IsEven n -> IsEven (2+n)

sumx : (n : Nat) -> {auto 0 prf1 : IsEven n} -> (m : Nat) -> {auto 0 prf2 : IsEven m} -> Nat
sumx n m = n + m
No tak to je teda hnusný zápis  :P :) Pak mi musíš vysvětlit, proč to tam je.

Bohužel: "Can't find an implementation for IsEven 2."
Jakou máš verzi Idrisu? Funguje to v 0.6.0.

idris2 --version # 0.6.0
Z idris2-0.6.0.tgz, stažený z webu, kompiluju na Fedoře.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 01:04:46
IsEven musí mít typový parametr. A je to jen kontrakt, že ten parametr je sudé číslo. Nějak takto to bude fungovat:
Kód: [Vybrat]
data IsEven : Nat -> Type where
    ZIsEven  : IsEven 0
    SuccSuccIsEven : IsEven n -> IsEven (2+n)

sumx : (n : Nat) -> {auto 0 prf1 : IsEven n} -> (m : Nat) -> {auto 0 prf2 : IsEven m} -> Nat
sumx n m = n + m
No tak to je teda hnusný zápis  :P :) Pak mi musíš vysvětlit, proč to tam je.

Bohužel: "Can't find an implementation for IsEven 2."
Jakou máš verzi Idrisu? Funguje to v 0.6.0.

idris2 --version # 0.6.0
Z idris2-0.6.0.tgz, stažený z webu, kompiluju na Fedoře.
Tam ten kód funguje, zkus to zkopírovat ještě jednou do zdrojáku.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 01:22:43
Tam ten kód funguje, zkus to zkopírovat ještě jednou do zdrojáku.

Kód: [Vybrat]
SuccSuccIsEven : IsEven n -> IsEven (2+n) -- fungujeversus
Kód: [Vybrat]
SuccSuccIsEven : IsEven n -> IsEven (n+2) -- nefunguje >:(

Tak mám spousta více či méně blbejch otázek:

1/ proč tam musím uvádět {auto 0 prf1 : IsEven n} ?
2/ proč je to mezi šipkama? Ta funkce má jen tři parametry, ne pět.
3/ co to vlastně to {auto 0 prf1 : IsEven n} říká?
4/ proč tam ten prf1 musí být, když tam nikde nefiguruje? Proč musí být různý? prf1 a prf2
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 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 (https://github.com/launchbadge/sqlx#compile-time-verification) 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)  ;D
Ano, přesně tak, je to jedna metrika a můj osobní pohled... Nemám v úmyslu ho vydávat za obecně závazný :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 01:44:32
Co znamená ta 0 mezi `auto` a jménem implicitního argumentu?
To je multiplicita (viz kvantitativní typový systém). Nula znamená erasure :)
Aha, ok. Dalo by se to principelně doplnit syntaxí s anonymním argumentem, něco jako `auto _ : IsEven n`? Anonymní arugment by nešlo ve funkci použít, tj. efektivně multiplicita 0. Edit: Resp. asi lepší syntaxe by byla `auto 0: IsEven n`.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 01:52:50
Co znamená ta 0 mezi `auto` a jménem implicitního argumentu?
To je multiplicita (viz kvantitativní typový systém). Nula znamená erasure :)
Aha, ok. Dalo by se to principelně doplnit syntaxí s anonymním argumentem, něco jako `auto _ : IsEven n`? Anonymní arugment by nešlo ve funkci použít, tj. efektivně multiplicita 0. Edit: Resp. asi lepší syntaxe by byla `auto 0: IsEven n`.
Jo, to jde.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 01:58:43
Tak mám spousta více či méně blbejch otázek:

1/ proč tam musím uvádět {auto 0 prf1 : IsEven n} ?
2/ proč je to mezi šipkama? Ta funkce má jen tři parametry, ne pět.
3/ co to vlastně to {auto 0 prf1 : IsEven n} říká?
4/ proč tam ten prf1 musí být, když tam nikde nefiguruje? Proč musí být různý? prf1 a prf2
1. To jsou prerekvizity, které chceš (sudost argumentů). To "auto" znamená, že si to má překladač ověřit sám.
2. To je jen konvence, implicitní parametry můžou být kdekoliv. Ta funkce má dva parametry a dvě prerekvizity.
3. IsEven n říká, že n je zaručeně sudé. A prf1/prf2 je prostě jméno té prerekvizity.
4. Jsou různé, protože máš dva vstupní parametry, které chceš mít sudé. Být tam musí, aby sis vynutil tu sudost (kdyby se to nepředávalo, na vstupu by mohlo být libovolné číslo).

Kdybych tam cpal čísla ze vstupu, musel bych si to ověření sudosti (prfX) vyrobit sám a předat ho explicitně.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 03:59:35
Kdybych tam cpal čísla ze vstupu, musel bych si to ověření sudosti (prfX) vyrobit sám a předat ho explicitně.

Mohl by si mi ukázat, jak by to vypadalo?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: oss 07. 12. 2022, 08:04:08
Mna by tiez zaujimalo, ako  si tieto super uzasne jazyky, ktore maju typ na parne cislo alebo neprazdny string (co sa da aj v tej heitovanej jave, ci C#) poradia so vstupmy od pouzivatela, ci ineho systemu, kde moze prist akakolvek blbost.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 08:37:12
Kdybych tam cpal čísla ze vstupu, musel bych si to ověření sudosti (prfX) vyrobit sám a předat ho explicitně.
Mohl by si mi ukázat, jak by to vypadalo?
Jasně, včera jsem to už zkoušel, abych viděl, jak se současná verze chová.
Kód: [Vybrat]
total main : IO ()
main = do
    Just n <- readNat | _ => putStrLn "not a natural number"
    let Yes _ = decIsEven n | _ => putStrLn "n isn't even"
    Just m <- readNat | _ => putStrLn "not a natural number"
    let Yes _ = decIsEven m | _ => putStrLn "m isn't even"
    putStrLn $ "Hello: " ++ (show (sumx n m))
Když tam nebude to let Yes ..., tak kód neprojde typovou kontrolou.

P.S. Psal jsem "předat explicitně", ale ve verzi 0.6.0 to už zřejmě není nutné, překladač si to ověření najde v ASTu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 10:44:34
co sa da aj v tej heitovanej jave, ci C#
Tak se předveď, ne?


poradia so vstupmy od pouzivatela, ci ineho systemu, kde moze prist akakolvek blbost.
Na tuto otázku tu již byla odpověď.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: oss 07. 12. 2022, 10:54:40
Tak se předveď, ne?

Pomocou value objektu (co realne aspon v C# nemusi byt objekt). To hadam takym amchrom na typy vysvetlovat nemusim.

Na tuto otázku tu již byla odpověď.

Mozes sem dat odkaz, lebo dost sa stracam v tejto diskusii, kedze sa tu hadate o milion veciach.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 11:02:56
Kód: [Vybrat]
total main : IO ()
main = do
    Just n <- readNat | _ => putStrLn "not a natural number"
    let Yes _ = decIsEven n | _ => putStrLn "n isn't even"
    Just m <- readNat | _ => putStrLn "not a natural number"
    let Yes _ = decIsEven m | _ => putStrLn "m isn't even"
    putStrLn $ "Hello: " ++ (show (sumx n m))

Tady by mě zajímalo, jaká jsou pravidla pro scoping té anonymní instance IsEven. Jak daleko může být od místa volání sumx, aby to kompilátor ještě našel / dosadil implicitní arg? Pokud by to bylo v externím kódu, muselo by se to třeba nějak importovat?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 11:12:21
Případně ještě se zeptám obecně: Jaké jsou v Haskellu a Idrisu pravidla ohledně koherence? Dejme tomu, že ve svém programu používám knihovny libA a libB, knihovna libA definuje typeclass Tc a libB typ Foo. Můžu instanciovat Tc pro Foo?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 11:13:43
Mna by tiez zaujimalo, ako  si tieto super uzasne jazyky, ktore maju typ na parne cislo alebo neprazdny string (co sa da aj v tej heitovanej jave, ci C#) poradia so vstupmy od pouzivatela, ci ineho systemu, kde moze prist akakolvek blbost.
Úplně stejně... tu příchozí hodnotu naparsuješ/dekóduješ a výsledkem takový operace je buď ten správný typ, nebo chyba...


Edit: Poznámka k:
Citace
Můžu instanciovat Tc pro Foo?
.. samozřejmě mám na mysli za předpokldau, že neexistuje duplicitní/konfliktní instance.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 11:19:36
Kód: [Vybrat]
total main : IO ()
main = do
    Just n <- readNat | _ => putStrLn "not a natural number"
    let Yes _ = decIsEven n | _ => putStrLn "n isn't even"
    Just m <- readNat | _ => putStrLn "not a natural number"
    let Yes _ = decIsEven m | _ => putStrLn "m isn't even"
    putStrLn $ "Hello: " ++ (show (sumx n m))
Tady by mě zajímalo, jaká jsou pravidla pro scoping té anonymní instance IsEven. Jak daleko může být od místa volání sumx, aby to kompilátor ještě našel / dosadil implicitní arg? Pokud by to bylo v externím kódu, muselo by se to třeba nějak importovat?
To nevím, specifikované to není a závisí to na verzi překladače (novější jsou chytřejší). Když to překladač nenajde, musí se předat explictně {prf1 = isevenN}.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 11:35:40
Tak se předveď, ne?

Pomocou value objektu (co realne aspon v C# nemusi byt objekt). To hadam takym amchrom na typy vysvetlovat nemusim.
Musíš. Protože tvrdím, že to nejde. Možná nechápeš zadání, a myslíš si, že když mi to vyhodí výjimku, že číslo není sudé, tak, že je splněno.

Na tuto otázku tu již byla odpověď.

Mozes sem dat odkaz, lebo dost sa stracam v tejto diskusii, kedze sa tu hadate o milion veciach.
https://forum.root.cz/index.php?topic=23802.msg380723#msg380723
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: oss 07. 12. 2022, 11:36:44
Mna by tiez zaujimalo, ako  si tieto super uzasne jazyky, ktore maju typ na parne cislo alebo neprazdny string (co sa da aj v tej heitovanej jave, ci C#) poradia so vstupmy od pouzivatela, ci ineho systemu, kde moze prist akakolvek blbost.
Úplně stejně... tu příchozí hodnotu naparsuješ/dekóduješ a výsledkem takový operace je buď ten správný typ, nebo chyba...

Vdaka za odpoved.

No v tom pripade mi tieto hadky nad typovym systemom pridu dost zbytocne.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: oss 07. 12. 2022, 11:38:41
Tak se předveď, ne?

Pomocou value objektu (co realne aspon v C# nemusi byt objekt). To hadam takym amchrom na typy vysvetlovat nemusim.
Musíš. Protože tvrdím, že to nejde. Možná nechápeš zadání, a myslíš si, že když mi to vyhodí výjimku, že číslo není sudé, tak, že je splněno.

Vid kralikovu odpoved.
Trik je v tom, ze instancia daneho value objektu nemoze vzniknut pokial sa nejedna o pare cislo.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 11:55:25
Mna by tiez zaujimalo, ako  si tieto super uzasne jazyky, ktore maju typ na parne cislo alebo neprazdny string (co sa da aj v tej heitovanej jave, ci C#) poradia so vstupmy od pouzivatela, ci ineho systemu, kde moze prist akakolvek blbost.
Úplně stejně... tu příchozí hodnotu naparsuješ/dekóduješ a výsledkem takový operace je buď ten správný typ, nebo chyba...

Vdaka za odpoved.

No v tom pripade mi tieto hadky nad typovym systemom pridu dost zbytocne.
Ale jistě. Jak jsem psal tady: https://forum.root.cz/index.php?topic=23802.msg380764#msg380764
"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)  ;D"


Tak se předveď, ne?

Pomocou value objektu (co realne aspon v C# nemusi byt objekt). To hadam takym amchrom na typy vysvetlovat nemusim.
Musíš. Protože tvrdím, že to nejde. Možná nechápeš zadání, a myslíš si, že když mi to vyhodí výjimku, že číslo není sudé, tak, že je splněno.

Vid kralikovu odpoved.
Trik je v tom, ze instancia daneho value objektu nemoze vzniknut pokial sa nejedna o pare cislo.
Třeba takhle?

Kód: [Vybrat]
[TestMethod]
public void Trik()
{
var input = 3;
var a = new Even(input);
var res = Sum(a, new Even(2));
}



private Even Sum(Even a, Even b)
{
}



class Even
{
private readonly int val;

public Even(int val)
{
assertEven(val);
this.val = val;
}
}
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: oss 07. 12. 2022, 12:14:00
Viem, kam smerujes, ale ked sa bavime o vstupoch od pouzivatela, tak:

Kód: [Vybrat]
new Even(input);
Je ekvivalentne.

Kód: [Vybrat]
let Yes _ = decIsEven n | _ => putStrLn "n isn't even"
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 12:24:56
Viem, kam smerujes, ale ked sa bavime o vstupoch od pouzivatela, tak:

Kód: [Vybrat]
new Even(input);
Je ekvivalentne.

Kód: [Vybrat]
let Yes _ = decIsEven n | _ => putStrLn "n isn't even"
Není.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 12:31:16
Je ekvivalentne.
Není.
Technicky vzato to ekvivalentní samozřejmě není (specificky tahle řádka uričtě ne), ale smysl kódu je v zásadě stejný. Na začátku se buď vytvoří hodnota daného typu, nebo se vyhodí chyba...

Liší se technické detaily, v Javě například to bude muset mít objekt, nebudeš moct použít infixové operátory a řada dalších technických rozdílů...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 13:11:01
Je ekvivalentne.
Není.
Technicky vzato to ekvivalentní samozřejmě není (specificky tahle řádka uričtě ne), ale smysl kódu je v zásadě stejný. Na začátku se buď vytvoří hodnota daného typu, nebo se vyhodí chyba...

Liší se technické detaily, v Javě například to bude muset mít objekt, nebudeš moct použít infixové operátory a řada dalších technických rozdílů...

Na technické detaily ti zvrací alík.

Liší se hlavně záruky.
V C# můžu tu validaci zapomenout. Skončí mi to výjimkou u assert v run-time. Zatímco v Idrisu mi to přinutí tu kontrolu udělat compile-time. To je ta zásadní motivace, proč se všechny ty šaškárny s typama dělají.

Idris mě přinutí tu kontrolu udělat.
C#, Java, Python mi tu kontrolu udělat nepřinutí. Data corupted sice nenastane (jsi-li alespoň trochu šikovnej), ale spadne to za běhu.

Do třetice:
V Idrisu (a Haskellu) - nalinkuju si nějakou knihovnu, použiju a pokusím se přeložit, a ono to začne řvát tady a tady a tady a tady... opravím, přeložím, běží.

V C# - nalinkuju si nějakou knihovnu, použiju, a úspěšně přeložím, spustím, a ono to začne padat tehdy, a tehdy, a tehdy, a tehdy... nejlépe u zákazníka.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 13:16:24
Viem, kam smerujes, ale ked sa bavime o vstupoch od pouzivatela, tak:

Kód: [Vybrat]
new Even(input);
Je ekvivalentne.

Kód: [Vybrat]
let Yes _ = decIsEven n | _ => putStrLn "n isn't even"
Není.
Nebo ty tam vidíš někde, že bych tu výjimku, kterou Even vyhazuje odchytával?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 13:29:25
Je ekvivalentne.
Není.
Technicky vzato to ekvivalentní samozřejmě není (specificky tahle řádka uričtě ne), ale smysl kódu je v zásadě stejný. Na začátku se buď vytvoří hodnota daného typu, nebo se vyhodí chyba...

Liší se technické detaily, v Javě například to bude muset mít objekt, nebudeš moct použít infixové operátory a řada dalších technických rozdílů...

Na technické detaily ti zvrací alík.

Liší se hlavně záruky.
V C# můžu tu validaci zapomenout. Skončí mi to výjimkou u assert v run-time. Zatímco v Idrisu mi to přinutí tu kontrolu udělat compile-time. To je ta zásadní motivace, proč se všechny ty šaškárny s typama dělají.

Idris mě přinutí tu kontrolu udělat.
C#, Java, Python mi tu kontrolu udělat nepřinutí. Data corupted sice nenastane (jsi-li alespoň trochu šikovnej), ale spadne to za běhu.

Do třetice:
V Idrisu (a Haskellu) - nalinkuju si nějakou knihovnu, použiju a pokusím se přeložit, a ono to začne řvát tady a tady a tady a tady... opravím, přeložím, běží.

V C# - nalinkuju si nějakou knihovnu, použiju, a úspěšně přeložím, spustím, a ono to začne padat tehdy, a tehdy, a tehdy, a tehdy... nejlépe u zákazníka.
Akorát cena za to je, že ty šikovné typy pro ověření musí někdo napsat. Pro základní věci (čísla, seznamy) je má standardní knihovna, nicméně pro méně typické věci (třeba i ta jednoduchá sudost) to musí napsat laskavý čtenář vývojář.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 13:31:03
Kdybych tam cpal čísla ze vstupu, musel bych si to ověření sudosti (prfX) vyrobit sám a předat ho explicitně.
Mohl by si mi ukázat, jak by to vypadalo?
BTW až se budeš cítit na definici decIsEven, dej vědět  ;)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 13:37:10
Akorát cena za to je, že ty šikovné typy pro ověření musí někdo napsat.
Já tu třídu v C# taky musel napsat.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: listoper 07. 12. 2022, 13:38:34
A abych byl hodně cynický, tak ona možná není nijak zvláštní poptávka ani po bezpečném kódu (Clojure...

triggered
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 13:42:37
C#, Java, Python mi tu kontrolu udělat nepřinutí. Data corupted sice nenastane (jsi-li alespoň trochu šikovnej), ale spadne to za běhu.
Bavíme se o vstupu od uživatele, tzn. tam z principu to musí vyhodit chybu za běhu při načítání dat. Pokud při načítání dat chyba nenastane a úspěšně je vytvořena příslušná hodnota příslušného typu v C# nebo Javě (o Py to neplatí), tak pak přece není už důvod, aby to padalo někde dále, ne?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 14:25:04
C#, Java, Python mi tu kontrolu udělat nepřinutí. Data corupted sice nenastane (jsi-li alespoň trochu šikovnej), ale spadne to za běhu.
Bavíme se o vstupu od uživatele, tzn. tam z principu to musí vyhodit chybu za běhu při načítání dat. Pokud při načítání dat chyba nenastane a úspěšně je vytvořena příslušná hodnota příslušného typu v C# nebo Javě (o Py to neplatí), tak pak přece není už důvod, aby to padalo někde dále, ne?
O to nejde.

Samozřejmě, že ten scénář musím zohlednit v runtime.

Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.

Částečně by toto řešil systém Checked Exception, od kterých se ale bohužel upouští. Úplně netuším proč. (C# je třeba schválně nemá.)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 14:26:17
Případně ještě se zeptám obecně: Jaké jsou v Haskellu a Idrisu pravidla ohledně koherence? Dejme tomu, že ve svém programu používám knihovny libA a libB, knihovna libA definuje typeclass Tc a libB typ Foo. Můžu instanciovat Tc pro Foo?

Na toto jsem nedostal odpověď, tak jsem se zeptal na SO (https://stackoverflow.com/questions/74715527/haskell-coherence-rules-wrt-external-code/74716275#74716275). TL;DR Haskell dovoluje orphan type instances vč. odvozených z dependencí. (Je Idris v tomto jiný? Asi bych to nečekal.)

@BoneFlute toto je příklad, kdy Rust musí omezovat typové abstrakce kvůli engineering constraints - nemůže dovolit orphan trait implementace na úrovni knihoven (na úrovni modulů ano), protože by to jednak způsobovalo semver hazardy a také pravděpodobně problémy s linkováním (zejména dynamickým), nejspíš by implementace traitů už nemohly být anonymní...

Zajímavé je, že Haskellu tohle nevadí, efektivně přidání jakékoli zvenku viditelné instance v knihovně je semver-incompatible změna...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 14:27:48
C#, Java, Python mi tu kontrolu udělat nepřinutí. Data corupted sice nenastane (jsi-li alespoň trochu šikovnej), ale spadne to za běhu.
Bavíme se o vstupu od uživatele, tzn. tam z principu to musí vyhodit chybu za běhu při načítání dat. Pokud při načítání dat chyba nenastane a úspěšně je vytvořena příslušná hodnota příslušného typu v C# nebo Javě (o Py to neplatí), tak pak přece není už důvod, aby to padalo někde dále, ne?
O to nejde.

Samozřejmě, že ten scénář musím zohlednit v runtime.

Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.

Částečně by toto řešil systém Checked Exception, od kterých se ale bohužel upouští. Úplně netuším proč. (C# je třeba schválně nemá.)
BTW v Idrisu jde garantovat i vlastnosti návratových hodnot, nejen vstupních parametrů.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 14:28:41
Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.
To je jedno ne? Hodnota toho typu nebude vytvořena, pokud konstruktor vyhodil výjimku...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 14:29:12
Akorát cena za to je,
Imho statické typy mají jiné problémy.
Namátkou:
- jsou náročné na čas výpočtu
- jsou náročné na vývoj jazyka
- jsou náročné na skill uživatele
- lidé nechápou co to je statické typování
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 14:30:38
Případně ještě se zeptám obecně: Jaké jsou v Haskellu a Idrisu pravidla ohledně koherence? Dejme tomu, že ve svém programu používám knihovny libA a libB, knihovna libA definuje typeclass Tc a libB typ Foo. Můžu instanciovat Tc pro Foo?

Na toto jsem nedostal odpověď, tak jsem se zeptal na SO (https://stackoverflow.com/questions/74715527/haskell-coherence-rules-wrt-external-code/74716275#74716275). TL;DR Haskell dovoluje orphan type instances vč. odvozených z dependencí. (Je Idris v tomto jiný? Asi bych to nečekal.)
Idris to má stejně.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 14:30:48
Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.
To je jedno ne? Hodnota toho typu nebude vytvořena, pokud konstruktor vyhodil výjimku...
Zákazník: Tak jsem zkoušel vaši aplikaci a je úplně k ničemu. Jsem tam normálně zadal číslo, a ono to spadlo.
Já: To je jedno ne?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 14:34:01
Akorát cena za to je,
Imho statické typy mají jiné problémy.
Namátkou:
- jsou náročné na čas výpočtu
- jsou náročné na vývoj jazyka
- jsou náročné na skill uživatele
- lidé nechápou co to je statické typování
Doplnění: Jsou náročné na čas výpočtu v době překladu, za běhu ne. Nicméně SPARK se svou formální verifikací je na tom hůře, kdysi na nějaké přednášce někdo z NASA vykládal, jak se jim kód překládá týden. Ale pak věděli, že je absolutně bezpečný :)

Ten zbytek platí, jde to shrnout do jednoho bodu o Inkových “mentálních obzorech”.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 14:35:43
Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.
To je jedno ne? Hodnota toho typu nebude vytvořena, pokud konstruktor vyhodil výjimku...
Zákazník: Tak jsem zkoušel vaši aplikaci a je úplně k ničemu. Jsem tam normálně zadal číslo, a ono to spadlo.
Já: To je jedno ne?
Slušný vývojář tu výjimku odchytí a vypíše třeba “Sorry vole error”.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 14:36:10
Zákazník: Tak jsem zkoušel vaši aplikaci a je úplně k ničemu. Jsem tam normálně zadal číslo, a ono to spadlo.
Já: To je jedno ne?
To je ale něco jiného, to spadlo, protože nebyla dobře ošetřena chyba, ne proto, že by byl porušen invariant.

To samé se stane v Rustu, pokud udělám `.unwrap()` na výsledku toho konstruktoru anebo v Haskellu, pokud bys např. v Either Left větvi udělal `error "shit's on fire yo"` ...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 14:36:22
Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.
To je jedno ne? Hodnota toho typu nebude vytvořena, pokud konstruktor vyhodil výjimku...
V Rustu to bude panic?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 14:37:21
Jsou náročné na čas výpočtu v době překladu, za běhu ne.
Ano, ano, sorry.
A platí o opak, že za běhu by to mělo být rychlejší. Žel, jak nám Králík ukázal, tak jen teoreticky. Což je taky smutné - takovej nevyužitej potenciál.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 14:38:42
Zákazník: Tak jsem zkoušel vaši aplikaci a je úplně k ničemu. Jsem tam normálně zadal číslo, a ono to spadlo.
Já: To je jedno ne?
To je ale něco jiného, to spadlo, protože nebyla dobře ošetřena chyba
Teď jsi na to kápnul, ten program v Idrisu se nepřeloží, pokud nejsou správně ošetřeny všechny chyby.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 14:40:00
Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.
To je jedno ne? Hodnota toho typu nebude vytvořena, pokud konstruktor vyhodil výjimku...
V Rustu to bude panic?
Je to stejně jako v Haskellu, panikovat v konstruktoru můžeš, ale slušné je vrátit `Result` což je to samé co `Either`...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 14:40:38
Jsou náročné na čas výpočtu v době překladu, za běhu ne.
Ano, ano, sorry.
A platí o opak, že za běhu by to mělo být rychlejší.
Taky že je, například v Julii (ta je extrabuřt, je dynamicky typovaná, ale pozná stabilně otypovaný kód a odvodí si všechny typy).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 14:42:09
Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.
To je jedno ne? Hodnota toho typu nebude vytvořena, pokud konstruktor vyhodil výjimku...
V Rustu to bude panic?
Je to stejně jako v Haskellu, panikovat v konstruktoru můžeš, ale slušné je vrátit `Result` což je to samé co `Either`...
Lepší by bylo si tu slušnost od autora kódu vynutit: Kašleš na chyby? Tak to mi můžeš, syntax error :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 14:45:42
Problém je v tom, že v Idrisu se mi nestane to, co se mi stane v C# v tom příkladu, který jsem uváděl. Že tu chybu neodchytím, tedy nezpracuji, tedy jsem tu chybu nezohlednil.
To je jedno ne? Hodnota toho typu nebude vytvořena, pokud konstruktor vyhodil výjimku...
Zákazník: Tak jsem zkoušel vaši aplikaci a je úplně k ničemu. Jsem tam normálně zadal číslo, a ono to spadlo.
Já: To je jedno ne?
Slušný vývojář tu výjimku odchytí a vypíše třeba “Sorry vole error”.
To je ale něco jiného, to spadlo, protože nebyla dobře ošetřena chyba, ne proto, že by byl porušen invariant.

To samé se stane v Rustu, pokud udělám `.unwrap()` na výsledku toho konstruktoru anebo v Haskellu, pokud bys např. v Either Left větvi udělal `error "shit's on fire yo"` ...
Ano, je to něco jiného. To je rozdíl mezi Idrisem a C#.

Idris:
kompilátor: hele, zapomněl jsi tady zohlednit tenhle scénář
já: nezajímá
kompilátor: mě taky ne, nepustím tě dál
já: ale já to chci přeložit.
kompilátor: nezajímá
já: štveš mě
kompilátor: nezajímá
já: grrr, SO, ha, mám to, musím tam narvat error()
kompilátor: když myslíš
já: :P

C#
kompilátor: přeloženo
reviewer: hele, hmm, neměl by si tady zohlednit tenhle scénář?
já: to se nestane
reviewer: no, já nevím
já: hele, šéfe, von mě zdržuje
šéf: to je v pořádku, pusť to
klient: ehm, pánové, to si to po sobě neumíte zkontrolovat? Padá to při třech scénářích
reviewer: třech?! Kde?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 14:47:21
Je to stejně jako v Haskellu, panikovat v konstruktoru můžeš, ale slušné je vrátit `Result` což je to samé co `Either`...
Lepší by bylo si tu slušnost od autora kódu vynutit: Kašleš na chyby? Tak to mi můžeš, syntax error :)
Meh. Tak mi ukaž, jak v Idrisu handluješ chybu alokace paměti. V Rustu to jde.

V Idrisu jsem taky našel funkci á la panic (builtins.idris_crash).

Věřim ti, že obecně Idris více tlačí uživatele do ošetření chyb, ale ten rozdíl je kvantitativní...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 14:51:09
Věřim ti, že obecně Idris více tlačí uživatele do ošetření chyb, ale ten rozdíl je kvantitativní...
Představuji si nástroj pro Rust, který projede kód a hledá výskyty slov panic().
Představuji si nástroj pro C#, který projede kód a dohledá všechny neošetřené scénáře... stále si představuji... stále si představuji...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 14:54:22
Představuji si nástroj pro C#, který projede kód a dohledá všechny neošetřené scénáře... stále si představuji... stále si představuji...
Já úplně nevím, proč se o tomhle se mnou přeš, já jsem odpůrce výjimek přesně z tohoto důvodu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 15:05:32
Je to stejně jako v Haskellu, panikovat v konstruktoru můžeš, ale slušné je vrátit `Result` což je to samé co `Either`...
Lepší by bylo si tu slušnost od autora kódu vynutit: Kašleš na chyby? Tak to mi můžeš, syntax error :)
Věřim ti, že obecně Idris více tlačí uživatele do ošetření chyb, ale ten rozdíl je kvantitativní...
Tak jistě, když se ti počítač vznítí a ty na něj chrstneš kýbl vody, tak to asi Idris nezachrání. Ale donutí tě náležitě ošetřit všechny logické chyby v kódu (typu dělení nulou, že se nevolá head na prázdný seznam apod.).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 15:13:53
V Idrisu jsem taky našel funkci á la panic (builtins.idris_crash).
Jenže to normálně použít nejde, jen ve funkci, která je explicitně partial, což se prakticky nepoužívá (a v produkci nikdy). Takže tohle se taky vůbec nepřeloží.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 15:17:23
jak v Idrisu handluješ chybu alokace paměti. V Rustu to jde.
Rust v tomto případě dělá abort (ani ne panic).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 15:35:58
Věřim ti, že obecně Idris více tlačí uživatele do ošetření chyb, ale ten rozdíl je kvantitativní...
Tak jistě, když se ti počítač vznítí a ty na něj chrstneš kýbl vody, tak to asi Idris nezachrání. Ale donutí tě náležitě ošetřit všechny logické chyby v kódu (typu dělení nulou, že se nevolá head na prázdný seznam apod.).
:) Pro nějakou definici "chyby" a pro nějakou definici "ošetří" tě Idris donutí ošetřit chyby...

jak v Idrisu handluješ chybu alokace paměti. V Rustu to jde.
Rust v tomto případě dělá abort (ani ne panic).
Takové je výchozí chování a popravdě třeba na Linuxu ani nemá smysl ho měnit, protože alokační chybu stejně nedostaneš. Ale lze změnit jak výchozí chování, tak i používat fallible konstruktory u Boxů, Veců apod. a bez toho by Rust nemohl být použit třeba v linux kernelu apod.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 15:39:28
Představuji si nástroj pro C#, který projede kód a dohledá všechny neošetřené scénáře... stále si představuji... stále si představuji...
Já úplně nevím, proč se o tomhle se mnou přeš, já jsem odpůrce výjimek přesně z tohoto důvodu.
Ten problém není ve výjimkách.

Přemýšlím, zda by typovej systém C# stačil na to, když by se ty chyby přepsaly na Either. To stojí za promyšlení. Kolik benefitů by to vlastně přineslo.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 15:39:46
Věřim ti, že obecně Idris více tlačí uživatele do ošetření chyb, ale ten rozdíl je kvantitativní...
Tak jistě, když se ti počítač vznítí a ty na něj chrstneš kýbl vody, tak to asi Idris nezachrání. Ale donutí tě náležitě ošetřit všechny logické chyby v kódu (typu dělení nulou, že se nevolá head na prázdný seznam apod.).
Pro nějakou definici "chyby" a pro nějakou definici "ošetří" tě Idris donutí ošetřit chyby...
Jo, ty definice sdílí se SPARKem (a jinými superbezpečnými jazyky pro bezpečnostně kritické aplikace).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 15:45:18
Přemýšlím, zda by typovej systém C# stačil na to, když by se ty chyby přepsaly na Either. To stojí za promyšlení. Kolik benefitů by to vlastně přineslo.
Na této úrovni jsou Java, C#, Rust a Go stejně dobré. Nebo špatné :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 16:15:37
Přemýšlím, zda by typovej systém C# stačil na to, když by se ty chyby přepsaly na Either. To stojí za promyšlení. Kolik benefitů by to vlastně přineslo.
Na této úrovni jsou Java, C#, Rust a Go stejně dobré. Nebo špatné :)

Ježiš, už mezi prvníma dvěma budou rozdíly... Java ani nemá hodnotvé typy, Either by musel být objekt, takže alokace, plus problém, že všechno je za nullable referencí, takže vrácení Either může být null... Oproti tomu v C# to AFAIK může být hodnotový typ. Taky má AFAIK už nějaký pattern matching...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 07. 12. 2022, 16:21:23
Přemýšlím, zda by typovej systém C# stačil na to, když by se ty chyby přepsaly na Either. To stojí za promyšlení. Kolik benefitů by to vlastně přineslo.
Na této úrovni jsou Java, C#, Rust a Go stejně dobré. Nebo špatné :)
Java ani nemá hodnotvé typy
No a co? Ty ovlivňují výkon, ale nijak nesouvisí s bezpečností kódu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 16:27:35
plus problém, že všechno je za nullable referencí, takže vrácení Either může být null... Oproti tomu v C#
No, ale od které verze? V praxi to vůbec nepozoruju.
A třeba to not null bych fakt moc rád používal.


Taky má AFAIK už nějaký pattern matching...
Ano. Nějaký.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: BoneFlute 07. 12. 2022, 17:35:34
plus problém, že všechno je za nullable referencí, takže vrácení Either může být null... Oproti tomu v C#
No, ale od které verze? V praxi to vůbec nepozoruju.
A třeba to not null bych fakt moc rád používal.
Tak tady přiznávám svou neznalost. Když místo class použiju struct, což by mělo být podle docky hodnotový typ, tak to skutečně nelze vytvořit null. A je to i v naší staré code base. S tím si budu hrát.

Díky Králík!
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 18:48:56
NP, já jinak vůbec csharpista nejsem, asi to budeš umět využít lépe než já, jenom mam tohle taknějak v paměti co jsem si o tom před časem někde četl + si vágně pamatuju, že to i generika nad těmahle hodnotama monomorfizuje v době načtání bytecode, ale to ber s rezervou, možná si to pamatuju blbě...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: listoper 07. 12. 2022, 19:49:59
Ježiš, už mezi prvníma dvěma budou rozdíly... Java ani nemá hodnotvé typy, Either by musel být objekt, takže alokace, plus problém, že všechno je za nullable referencí, takže vrácení Either může být null... Oproti tomu v C# to AFAIK může být hodnotový typ. Taky má AFAIK už nějaký pattern matching...

Jen pro info... java ma pattern matching... a value objects (primitive classes) jsou na ceste... JEP 401
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 07. 12. 2022, 20:14:00
Jen pro info... java ma pattern matching...
Měl jsem dojem, že umí matchovat jenom typ objektu...

a value objects (primitive classes) jsou na ceste... JEP 401
To je zajímavé, je fajn, že se něco děje po tom, co vallhala nedopadla... Nicméně v tomhle případě by nám to nepomohlo, protože jestli to dobře chápu, ty typy nebudou moct být generické...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: listoper 07. 12. 2022, 21:05:36
Jen pro info... java ma pattern matching...
Měl jsem dojem, že umí matchovat jenom typ objektu...

Ma Guarded patterns a destructuring (aspon ve switch):
Kód: [Vybrat]

    record Person(String firstname, String surname) {}
    record Couple(Person p1, Person p2) {}

    public static void main(String[] args) {
        Person daddy = new Person("John", "Doe");
        Person mommy = new Person("Jane", "Doe");
        Person uncle = new Person("John", "Apples");


        var objects = Arrays.asList(
                new Couple(daddy, mommy),
                new Couple(mommy, daddy),
                new Couple(uncle, daddy),
                10,
                "Random string");

        objects.stream()
                .map(i -> switch (i) {
                    case Couple(Person p1, Person p2)
                            when p1.firstname.equals(p2.firstname)    -> (Supplier<String>) () -> "Split it in half between " + p1 + " and " + p2;
                    case Couple c
                            when c.p1.firstname.equals("John")        -> (Supplier<String>) () -> "Daddy is paying";
                    case Couple c
                            when c.p1.firstname.equals("Jane")        -> (Supplier<String>) () -> "Mommy is paying";
                    case Integer ignored                              -> (Supplier<String>) () -> "What are you doing here Integer";
                    case Object ignored                               -> (Supplier<String>) () -> "Runners... call 911";
                })
                .forEach(i -> System.out.println(i.get()));
    }

a value objects (primitive classes) jsou na ceste... JEP 401
To je zajímavé, je fajn, že se něco děje po tom, co vallhala nedopadla... Nicméně v tomhle případě by nám to nepomohlo, protože jestli to dobře chápu, ty typy nebudou moct být generické...
Myslim, ze je to porad valhalla... A nevim jestli budou moct byt genericke... spis ne
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 08. 12. 2022, 00:59:56
Představuji si nástroj pro C#, který projede kód a dohledá všechny neošetřené scénáře... stále si představuji... stále si představuji...
Já úplně nevím, proč se o tomhle se mnou přeš, já jsem odpůrce výjimek přesně z tohoto důvodu.
Ten problém není ve výjimkách.
A v čem?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: snugar_i 08. 12. 2022, 07:18:52
Ma Guarded patterns a destructuring (aspon ve switch):
Kód: [Vybrat]

    record Person(String firstname, String surname) {}
    record Couple(Person p1, Person p2) {}

    public static void main(String[] args) {
        Person daddy = new Person("John", "Doe");
        Person mommy = new Person("Jane", "Doe");
        Person uncle = new Person("John", "Apples");


        var objects = Arrays.asList(
                new Couple(daddy, mommy),
                new Couple(mommy, daddy),
                new Couple(uncle, daddy),
                10,
                "Random string");

        objects.stream()
                .map(i -> switch (i) {
                    case Couple(Person p1, Person p2)
                            when p1.firstname.equals(p2.firstname)    -> (Supplier<String>) () -> "Split it in half between " + p1 + " and " + p2;
                    case Couple c
                            when c.p1.firstname.equals("John")        -> (Supplier<String>) () -> "Daddy is paying";
                    case Couple c
                            when c.p1.firstname.equals("Jane")        -> (Supplier<String>) () -> "Mommy is paying";
                    case Integer ignored                              -> (Supplier<String>) () -> "What are you doing here Integer";
                    case Object ignored                               -> (Supplier<String>) () -> "Runners... call 911";
                })
                .forEach(i -> System.out.println(i.get()));
    }
No.. slušelo by se říct, že je to "preview feature" v nejnovější JDK 19 (tj. běžně se to zatím použít nedá a možná to nakonec ani nebude vypadat takhle) a funguje to jenom na recordy a jen ve switchi (což jsi teda napsal) - ve srovnání s tím, co umí třeba jenom Scala, je to stále úsměvný. Btw vůbec nechápu, proč je tam ten Supplier, zbytečně to ten příklad komplikuje, proč to neni jenom
Kód: [Vybrat]
objects.stream()
                .map(it -> switch (it) {
                    case Couple(Person p1, Person p2)
                            when p1.firstname.equals(p2.firstname)    -> "Split it in half between " + p1 + " and " + p2;
                    case Couple c
                            when c.p1.firstname.equals("John")        -> "Daddy is paying";
                    case Couple c
                            when c.p1.firstname.equals("Jane")        -> "Mommy is paying";
                    case Integer ignored                              -> "What are you doing here Integer";
                    case Object ignored                               -> "Runners... call 911";
                })
                .forEach(it -> System.out.println(it));
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: listoper 08. 12. 2022, 09:12:46
Ma Guarded patterns a destructuring (aspon ve switch):
...
No.. slušelo by se říct, že je to "preview feature" v nejnovější JDK 19 (tj. běžně se to zatím použít nedá a možná to nakonec ani nebude vypadat takhle) a funguje to jenom na recordy a jen ve switchi (což jsi teda napsal) - ve srovnání s tím, co umí třeba jenom Scala, je to stále úsměvný. Btw vůbec nechápu, proč je tam ten Supplier, zbytečně to ten příklad komplikuje, proč to neni jenom


Jo pravda... nedavno sem si tim hral a mezitim sem zapomel, ze mam zapnute preview features.
Nicmene s tim when je to uz asi treti verze preview (predtim bylo myslim &&) tak uz docela verim, ze to tak zustane...

Ty lambdy jsem tam dal, protoze je to expression switch a ja chtel ukazat ze na zaklade pattern matchingu muzu volat funkce a ne jen vracet string...

A ten pattern matching funguje ne jen na recordy:
Kód: [Vybrat]
        var objs = Arrays.asList(
                Optional.of("some string"),
                Optional.of(10),
                Optional.empty()
        );

        objs.stream()
                .map(i -> switch (i){
                    case Optional o when o.isPresent() && o.get() instanceof String -> "I have a string";
                    case Optional o when o.isPresent() && o.get() instanceof Integer -> "I have an Integer";
                    default -> "I don't know what I have";
                })
                .forEach(System.out::println);

Ten destructuring zatim as ano, ale support je taky na ceste
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 14. 12. 2022, 22:55:45
Jsou náročné na čas výpočtu v době překladu, za běhu ne.
Ano, ano, sorry.
A platí o opak, že za běhu by to mělo být rychlejší […] teoreticky. Což je taky smutné - takovej nevyužitej potenciál.
Tohle mi vrtalo hlavou, tak jsem zkusil kus reálně používaného kódu přepsat do (čistě funkcionálního) Leanu a ejhle, jsme s rychlostí na úrovni Rustu. Není to sice (formálně mnohem silnějším) typovým systémem, ale to by bylo nadlouho.

Jestli ses na Lean zatím nekoukal, tak doporučuji aspoň letmé seznámeni. Má například “locally imperative code blocks” ;)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 16. 12. 2022, 21:25:05
Jsou náročné na čas výpočtu v době překladu, za běhu ne.
Ano, ano, sorry.
A platí o opak, že za běhu by to mělo být rychlejší […] teoreticky. Což je taky smutné - takovej nevyužitej potenciál.
Tohle mi vrtalo hlavou, tak jsem zkusil kus reálně používaného kódu přepsat do (čistě funkcionálního) Leanu a ejhle, jsme s rychlostí na úrovni Rustu. Není to sice (formálně mnohem silnějším) typovým systémem, ale to by bylo nadlouho.

Jestli ses na Lean zatím nekoukal, tak doporučuji aspoň letmé seznámeni. Má například “locally imperative code blocks” ;)
Doplnění: V Idrisu jsem doimplementoval FBIP pro pole a hurá sláva, rychlost se limitně blíží verzi v Leanu. Ten Chez je fakt raketa :o No nic, dám si Guinness a pak jdu slavit :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 18. 12. 2022, 13:17:52
A ten kus kódu by byl?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: APhacker_mob 18. 12. 2022, 19:11:04
A ten kus kódu by byl?

 Toho se od Idrise nedockas.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 19. 12. 2022, 16:17:07
A ten kus kódu by byl?
Kód: [Vybrat]
inductive Edge : Type where
| mkEdge : Nat -> Nat -> String -> Nat -> List Edge -> Edge

def Edge.left : Edge -> Nat
| mkEdge left _ _ _ _ => left

def Edge.right : Edge -> Nat
| mkEdge _ right _ _ _ => right

def Edge.category : Edge -> String
| mkEdge _ _ category _ _ => category

def Edge.level : Edge -> Nat
| mkEdge _ _ _ level _ => level

def Edge.children : Edge -> List Edge
| mkEdge _ _ _ _ children => children

partial def Edge.tree (edge : Edge) : String :=
  edge.category ++
  if edge.children.isEmpty then "" else
  "(" ++ (edge.children.map fun e => e.tree).foldl (fun x y => x ++ (if x == "" then "" else ",") ++ y) "" ++ ")"

structure Chart where
  edges : Array (List Edge)

def mkChart (len : Nat) : Chart := { edges := mkArray len [] }

def addEdge (chart : Chart) (edge : Edge) : Chart :=
  let idx := edge.left
  { chart with edges := chart.edges.set! idx (edge :: chart.edges[idx]!) }

def addEdges (chart : Chart) : List Edge -> Chart
| [] => chart
| e :: es => addEdges (addEdge chart e) es

structure Rule where
  lhs : String
  rhs : List String

mutual
  partial def applyRule'' (lhs : String) (rhs : List String) (chart : Chart) (start : Nat) (maxLevel : Nat) (children : List Edge) (edge : Edge) (level : Nat) : List Edge :=
    match rhs with
    | r :: rs =>
      if r == edge.category then
        let maxLevel := if edge.level > maxLevel then edge.level else maxLevel
        if rs == [] then
          if maxLevel == level then
            [.mkEdge start edge.right lhs (level+1) children.reverse]
          else []
        else if edge.right < chart.edges.size then
          applyRule' lhs rs chart chart.edges[edge.right]! start maxLevel children level
        else []
      else []
    | [] => []

  partial def applyRule' (lhs : String) (rhs : List String) (chart : Chart) (edges : List Edge) (start : Nat) (maxLevel : Nat) (children : List Edge) (level : Nat) : List Edge :=
    match edges with
    | [] => []
    | e :: es => applyRule'' lhs rhs chart start maxLevel (e :: children) e level ++ applyRule' lhs rhs chart es start maxLevel children level
end

partial def applyRule (rule : Rule) (chart : Chart) (idx : Nat) (level : Nat) : List Edge :=
  if idx == chart.edges.size then [] else
  applyRule' rule.lhs rule.rhs chart chart.edges[idx]! idx 0 [] level ++ applyRule rule chart (idx+1) level

def applyRules'' (rules : List Rule) (chart: Chart) (level : Nat) : List Edge :=
  match rules with
  | [] => []
  | r :: rs => applyRule r chart 0 level ++ applyRules'' rs chart level

partial def applyRules' (rules : List Rule) (chart: Chart) (level : Nat) : Chart :=
  let newEdges := applyRules'' rules chart level
  if newEdges.isEmpty then chart else applyRules' rules (addEdges chart newEdges) (level+1)

def applyRules (rules : List Rule) (chart: Chart) : Chart :=
  applyRules' rules chart 0
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 22. 12. 2022, 09:25:41
Dík, ale myslel jsem spíš v Rustu.

Jinak nedávno kolega v práci ukazoval zajímavou vlastnost const funkcí v Rustu - je možné v nich psát asserty, a tím pádem staticky verifikovat některé invarianty. Ukazoval, že může vytvořit pole statické velikosti, protlačit to skrz nějaký 3rd party kód jako slice (dynamická velikost) a na druhém konci zkonvertovat zpátky na původní typ (konstantní velikost), s tím, že kompilátor velikost ověří staticky, nemusí se dělat runtime check.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 22. 12. 2022, 11:32:20
Jinak nedávno kolega v práci ukazoval zajímavou vlastnost const funkcí v Rustu - je možné v nich psát asserty, a tím pádem staticky verifikovat některé invarianty. Ukazoval, že může vytvořit pole statické velikosti, protlačit to skrz nějaký 3rd party kód jako slice (dynamická velikost) a na druhém konci zkonvertovat zpátky na původní typ (konstantní velikost), s tím, že kompilátor velikost ověří staticky, nemusí se dělat runtime check.
No vidíš, to je přesně ono, ověřování invariantů. Rozdíl je jen v tom, že v jazycích jako Idris či Lean (nebo SPARK, ale tam se používá jiná metoda) překladač provede verifikace při překladu (nemusí se dělat runtime check), i když velikost není konstantní. (Už to asi nechceme hlouběji rozebírat, ale umožňují to sigma typy. Jinak jo, v Rustu se dá s generickými parametry taky dělat psí kusy a časem třeba přidají i něco à la Lean, nejen typy, ale i plnohodnotnou funkcionální sémantiku - Swift už ji nějakou dobu má, takže je ověřené, že to jde i v tomto typu jazyků.)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 22. 12. 2022, 11:53:30
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/  :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 22. 12. 2022, 21:33:26
No vidíš, to je přesně ono, ověřování invariantů. Rozdíl je jen v tom, že v jazycích jako Idris či Lean (nebo SPARK, ale tam se používá jiná metoda) překladač provede verifikace při překladu (nemusí se dělat runtime check), i když velikost není konstantní. (Už to asi nechceme hlouběji rozebírat, ale umožňují to sigma typy. Jinak jo, v Rustu se dá s generickými parametry taky dělat psí kusy a časem třeba přidají i něco à la Lean, nejen typy, ale i plnohodnotnou funkcionální sémantiku
Tak počítám, že tohle by se dalo udělat i s dynamickým polem, ono je celkem jedno, jak ten invariant vyrobim. Ale nezkoušel jsem si to zatim. 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, ne pro postgraduální bádání apod. Když už, tak se spíš teď mudruje nad efekty, resp. specificky control-flow efekty, kvůli error handlingu, generátorům, async streamům apod. Opět ale nečekej nějaký těžce obecný systém, pravděpodobně by to přinejlepším byl opět nějaký subset, se zaměřením na zero-costness, ergnomii a nepříliš strmou učící křivku spíš než krásy typových systémů.

Swift už ji nějakou dobu má, takže je ověřené, že to jde i v tomto typu jazyků.
Jakou featuru Swiftu máš na mysli? Jinak Swift není stejný typ jazyka, nezaměřuje se na zero-cost abstrakce, má runtime, OOP s implicitním dynamic dispatchem,...

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
, takže by se musela třeba napsat nějaká traita a tu pak implementovat pro typy, které bys chtěl fixovat.  S makrama by to mělo být bez problému. Ono koneckonců v tom C++ je to trochu švindl, protože ty templaty jsou duck typing, žejo...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 22. 12. 2022, 21:44:20
Jo a taky lepší podpora self-referential types - to by Rustu pomohlo víc než jakékoli další FP featury...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 22. 12. 2022, 22:25:19
Jakou featuru Swiftu máš na mysli?
Myslel jsem klasický FBIP. Ale v Rustu by to asi nebylo žádné terno, když nad tím tak přemýšlím.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 22. 12. 2022, 22:27:43
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?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 22. 12. 2022, 22:34:35
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?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 22. 12. 2022, 22:40:34
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?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 22. 12. 2022, 22:54:14
Když už, tak se spíš teď mudruje nad efekty, resp. specificky control-flow efekty, kvůli error handlingu, generátorům, async streamům apod. Opět ale nečekej nějaký těžce obecný systém, pravděpodobně by to přinejlepším byl opět nějaký subset, se zaměřením na zero-costness, ergnomii a nepříliš strmou učící křivku spíš než krásy typových systémů.
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?)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 23. 12. 2022, 00:01:26
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 (https://blog.tonari.no/why-we-love-rust) k tomu došli...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 00:07:10
Lean neznám, ale pokud se může překládat do C++, tak by to asi do Rustu mělo jít taky...
To si myslím taky.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 00:12:07
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ě
To mi je tak nějak jasné, ale benchmarky mluví jasně (reálné, ne mikrokraviny). Hodnoceno střízlivě, zmíněné FBIP nebo obecně LLVM a jeho optimalizace nijak nezávisí na jazyce, z kterého se překládá. Takže, kde přesně má Rust navrch?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 23. 12. 2022, 00:32:31
Benchmarky málokdy mluví jasně. LLVM optimalizace závisí na vstupním IR kódu - není problém vyprodukvoat velmi těžko optimalizovatelný IR, koneckonců, pomalý kód je bez problému možné psát i v C. Rust je rychlý z podobného důvodu jako C nebo C++.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 00:35:44
Benchmarky málokdy mluví jasně. LLVM optimalizace závisí na vstupním IR kódu - není problém vyprodukvoat velmi těžko optimalizovatelný IR, koneckonců, pomalý kód je bez problému možné psát i v C. Rust je rychlý z podobného důvodu jako C nebo C++.
Fajn, takže Julia nebo Lean vedou k nadmíru optimalizovatelnému IR kódu.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 23. 12. 2022, 01:00:55
Jo to já nevim, já ho neviděl...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 01:07:46
Jo to já nevim, já ho neviděl...
Je stejně efektivní jako z Rustu ;) Nicméně upřímně, fakt bych rád viděl, kde Rust vede, srovnatelná efektivita dynamických jazyků je tak trochu puzzling.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 23. 12. 2022, 01:30:35
No mně to zatím puzzling nepřijde, až uvidim evidence, tak to třeba puzzling bude :)
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 02:15:27
No mně to zatím puzzling nepřijde, až uvidim evidence, tak to třeba puzzling bude :)
No jo, ignorance is bliss.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 23. 12. 2022, 09:14:47
Ingorance čeho?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 10:12:53
Ingorance čeho?
Faktu, že stejný kód (přesněji stejný algoritmus) je stejně efektivní jak v Rustu/C++/Go, tak dynamicky typovaných jazycích (tedy jen některých — Chez, Julia, Lean, ale dokazuje to, že v principu nejsou o nic pomalejší a rozhoduje jen kvalita implementace).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 23. 12. 2022, 11:22:48
Žádný takový fakt nebyl prokázán.

Ale jinak je samozřejmě možné, že takové algoritmy existují, a také není novinka, že z dynamického jazyka lze ždímat výkon - viz třeba asm.js na V8.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 11:48:22
Žádný takový fakt nebyl prokázán.
Viz (vědecké) články o vnitřnostech Leanu od jeho autorů, které popisují srovnání a benchmarky + diskuse o nich na odborných fórech (přece jen je to od Microsoft Research, ti mají obrovské peníze na vývoj i konference). To je to “ignorance is bliss” BTW :D
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 23. 12. 2022, 12:58:59
Žádný takový fakt nebyl prokázán.
Viz (vědecké) články o vnitřnostech Leanu od jeho autorů, které popisují srovnání a benchmarky + diskuse o nich na odborných fórech (přece jen je to od Microsoft Research, ti mají obrovské peníze na vývoj i konference). To je to “ignorance is bliss” BTW :D

:)

GOTO #451. Před 15-20 lety se diskutovalo, jak se HotSpot zlepšuje a jak bude BrzoTM Java rychlejší než C++, Sun měl taky obrovské peníze na vývoj a konference, byly předkládány benchmarky (https://web.archive.org/web/20200424183315/http://scribblethink.org/Computer/javaCbenchmark.html) ukazující, jak je rychlejší než C++ ... Tím neříkám, že ten výzkum a ty dané jazyky nejsou zajímavé, je asi dobře, že se tim někdo zabývá ... ale jaksi nemůžu nepozorovat, že tady existuje určitý opakující se pattern :)

Ale třeba to teď půjde lépe, když Rust přiměl FPčkaře se trochu více zabývat lineráními typy :P :D
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 13:04:21
Před 15-20 lety se diskutovalo, jak se HotSpot zlepšuje a jak bude BrzoTM Java rychlejší než C++, Sun měl taky obrovské peníze
Tak zrovna JIT Javy (potažmo JVM) generuje hodně rychlý kód, který se hravě C++, Rustu a Go vyrovná. Slabinou Javy (JVM) je způsob správy paměti, všechno se tupě alokuje na haldě, nedělá se pořádná escape analýza (ta, co se provádí, je jen kvůli synchronizaci), takže to vypadá, jak to vypadá (jako kdyby se v Rustu pro úplně všechny proměnné dělalo Box::new nebo Rc::new). Takže fakt hodně blbě zvolený příklad.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 13:08:38
když Rust přiměl FPčkaře se trochu více zabývat lineráními typy
Až na to, že ta kauzalita je opačná, autoři Rustu se netají tím, že se inspirovali starými jazyky s lineárními typy, sám Hoare prostě obšlehl způsob práce se zdroji v Mercury (jazyk z roku 1995). Tohle ti dost nevyšlo :P
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 23. 12. 2022, 13:36:30
když Rust přiměl FPčkaře se trochu více zabývat lineráními typy
Až na to, že ta kauzalita je opačná, autoři Rustu se netají tím, že se inspirovali starými jazyky s lineárními typy, sám Hoare prostě obšlehl způsob práce se zdroji v Mercury (jazyk z roku 1995). Tohle ti dost nevyšlo :P
Ano, jistě, kromě Mercury také Linear ML a nějaké další ještě obskurnější jazyky. Přesně proto jsem napsal přiměl více zabývat - dnes to chce každej a jeho babička :D
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 13:46:35
Přesně proto jsem napsal přiměl více zabývat
Jak jsem ti vysvětlil, není to pravda, představa, že Rust nějak ovlivňuje FP, je ostatně dost směšná ;D

Nakonec to je ale jedno, hádat se s někým, kdo ignoruje zjevná fakta, nemá smysl.

Z jiného soudku (asi spíše pro BoneFlute): Nedávno jsem narazil na zajímavý jazyk, který má statický typový systém strukturně jednodušší než "obvyklí podezřelí" (Java/C++/Rust/Go), ale formálně silnější z pohledu OOP (restriktivní dědičnost) i HKT (metagenerické typy). Teď nemám po ruce odkaz, ale je popsaný na Wikibooks (pod něčím jako "Type-oriented programming", teď fakt nevím), večer můžu dát link a vysvětlit, co by si z něj Rust mohl vzít, aby byl praktičtější.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 23. 12. 2022, 15:09:55
Přesně proto jsem napsal přiměl více zabývat
Jak jsem ti vysvětlil, není to pravda, představa, že Rust nějak ovlivňuje FP, je ostatně dost směšná ;D
Tvoje poznámka o Mercury to nijak nerozporuje, naopak, přesně o tom mluvim - ten koncept byl 20 let na okraji zájmu, pak je použil Rust, a následně se vyrojilo X iniciativ/jazyků s linear types (Haskell linear types, Idris2), viz také ta Jonesovo přednáška, kde přímo Rust zmiňuje. Ale no nic no, tušil jsem, že ta myšlenka pro tebe bude kulturně nepřijatelná...

Z jiného soudku (asi spíše pro BoneFlute): Nedávno jsem narazil na zajímavý jazyk, který má statický typový systém strukturně jednodušší než "obvyklí podezřelí" (Java/C++/Rust/Go), ale formálně silnější z pohledu OOP (restriktivní dědičnost) i HKT (metagenerické typy). Teď nemám po ruce odkaz, ale je popsaný na Wikibooks (pod něčím jako "Type-oriented programming", teď fakt nevím), večer můžu dát link a vysvětlit, co by si z něj Rust mohl vzít, aby byl praktičtější.
Skoro bych býval hádal jazyk Kind (https://github.com/Kindelia/Kind), ovšem až na to OOP.

Jinak lidi pracující na Rustu mají představu kam ten jazyk rozvíjet, aby byl praktičtější, už jsem zmiňoval efekty, iniciativa v tomhle směru je tady (https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-generics.html) a tady (https://areweyeetyet.rs/), dále lepší práce s dyn traity a DSTs, případně vylepšování borrow-checkingu (do toho spadají i ty self-ref typy, stacked borrows a tak).

Nejsem si jistej, jestli tvoje představa o praktičnosti se shoduje se zaměřením toho jazyka...
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 15:20:15
Skoro bych býval hádal jazyk Kind (https://github.com/Kindelia/Kind), ovšem až na to OOP.
Ne, Kind je, pokud vím, čistě funkcionální.

Právě to OOP, ať už si o něm myslíme cokoliv, se dá udělat použitelně, jak je na nějakých (okrajových) jazycích vidět.

K té praktičnosti Rustu, kdy bude použitelné Any?
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Králík 23. 12. 2022, 16:51:28
K té praktičnosti Rustu, kdy bude použitelné Any?
Jakej máš na to požadavek? Ale ono je to asi jedno, Any je jen jednoduchý typ ve stdlib, není v něm vůbec žádná magie, veškerá zajímavá funcionalita plyne z dyn Any, takže počítám, že pravděpodobně se tím zabývá ta iniciativa kolem lepších dyn trait.

Ještě BTW našel jsem zápisek (https://graydon2.dreamwidth.org/253769.html) (5 let starý) od Graydona o možných budoucích směrech vývoje. Hodně high-level, ale docela dobré IMO.
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 17:24:53
K té praktičnosti Rustu, kdy bude použitelné Any?
Jakej máš na to požadavek?
Nic zvláštního, kód v Rustu píšu zásadně bez Any, ale obecně by bylo hezké, kdyby byl k dispozici nějaký type switch (jako ve Fortranu nebo Go, nemusí to být žádná divočina jako třeba v ObjC).
Název: Re:Je Rust jazyk budoucnosti?
Přispěvatel: Idris 23. 12. 2022, 17:31:48
Ještě BTW našel jsem zápisek (https://graydon2.dreamwidth.org/253769.html) (5 let starý) od Graydona o možných budoucích směrech vývoje. Hodně high-level, ale docela dobré IMO.
Zajímavé, zmiňuje Koku, což je předchůdce (nebo bratříček?) Leanu. Jo, dobrý přehled, ale nějak se to ubíralo jiným směrem.