Názory k článku Rust: funkce, lambda výrazy a rozhodovací konstrukce match

Podrobný článek vítám.

Zajímalo by mě, jak je to s čárkou za poslední větví konstrukce match. Většinou ji tam máte a jednou ne.

Vzhledem k tomu ze to vypadá jako kopie jazyka Erlang, dovolim jsi odpovědět.

Jedna se o defaultni větev. Když pravidla před tim nezaberou, tak udělej tohle.

Pokud takova větev v rozhodování není a nic nezabere, v Erlangu se vyvolá výjimka. Tady nevím.

Ty funkce co se s nimi muže pracovat jako s daty jako by z oka vypadly funs z Erlangu.

Defaultní větev se dělá pomocí _. Čárka za posledním prvkem nemá žádný význam (podobně jako v jiných jazycích), je to příjemné pro přidávání dalších prvků (nebo odebírání), jelikož není nutné podle kontextu čárku přidávat nebo mazat.

Však se v článku píše: "Ve skutečnosti překladač kontroluje, zda je _ použit, protože je vyžadováno, aby větve v konstrukci match pokryly všechny možné hodnoty testovaného výrazu"

a hned pod tím je ukázka. Takže to vypadá, že Rust si to kontroluje, Erlang ne (vůbec ne?) a C na to kašle a jen někdy vypíše warning, když se dobře nastaví přepínače. Těžko říct, co je nejlepší.

Tak podle me je nejlepsi aby se to kontrolovalo, tak jak to dela Rust ci jazyk D. Teda jazyk D ma i verzi switche ktery default nepotrebuje pokud se switch provadi nad vyctovym seznamem a jsou pouzity vsechny prvky s vyctoveho seznamu - coz dava smysl.

Rust kontroluje jestli jsou pokryty všechny možnosti a že všechny větve vrací stejný datový typ. Jde to docela ruku v ruce. Je to někdy docela otrava když vím, že nějaká možnost nemůže nastat (třeba x%2 je jen 0 nebo 1, ale match vyžaduje i vše ostatní). Tam se dá použít macro třeba unreachable!() nebo panic!() které obě mají univerzální návratovou hodnotu a schodí program pokud na ně dojde.

Co se '_' týče, je třeba to brát jako pattern. '_' nevytváří žádnou dočasnou proměnnou. Stejně tak by se pro vyčerpání všech možností dala proměnná pojmenovat (nebo všechny hodnoty pokrýt ručně). Patterny se pak vyskytují i u deklarací proměnných. Docela dobré když funkce vrací enum s několika hodnotami a já chci jen jednu. Nebo pro for cylkus když nijak nepotřebuju i.

Čárky nejsou povinné pokud je ve větvi tělo {} a na poslední větvi, ale automatické formátovače (třeba rustfmt plugin pro cargo) je za těli odebírá a na poslední příkazy přidává.

Díky. Vypadá to divně, ale aspoň v tom je nějaký systém.

Je vhodny Rust pro numericke vypocty? Obsahuje nejake optimalizovane knihovny napriklad pro maticove nasobeni?

R, Python, Fortran a Julia Ti nestačí?

Asi hledá srozumitelný jazyk, kde rychlost nezabije tím, že v tom jazyce napíše for cyklus (což se může stát v R, Pythonu i Julii).

Máš nějaký příklad z praxe?

Třeba implementace Kalmanova filtru? Jako jsou řešení jako např. Cython, ale pokud by to nějaký jazyk zvládal nativně, bylo by to fajn :-)

Co je na Fortranu nesrozumitelného?

https://github.com/kud1ing/awesome-rust#computation

Wow. Rust je podstatne zivejsi, nez jsem si myslel.

Nevím jak vám se to ukazuje, ale já vidím Rust na Githubu mezi 5 nejaktivnějšími a nejpopulárnějšími jazyky.

Nějaká nuimerické a algebraické knihovny tu jsou, ale je to dost fragmentované:

num - další numerické typy (bigint, complex, ...)
nalgebra - dobře optimalizovaná lineární algebra pro nízké dimenze
ndarray - N-dimenzionální matice a metody na nich

Letos na RustConf byli nějací chlapíci s machine learningem a docela shrnuli co od toho očekávat:
https://www.youtube.com/watch?v=lY10kTcM8ek
Není to moc pro prototypování protože to není dynamickty typovaný jazyk, není interpretovaný a nemá moc vizualizační nástroje. Ale je rychlý, dobře se paralelizuje, dobrý networking, error handling atd.

Ano, to je velmi dobré shrnutí - na prototypy to není dobrý jazyk, to raději použít IPython notebook nebo i to Rko. Ale pokud někoho pálí výkon už má navržené algoritmy, tak směle řekněme "in Rust we trust" :-)

Ty jsi mi ukradl me moto. Dokonce jsem si vyrobil tricko.

https://scontent-frt3-1.xx.fbcdn.net/v/t1.0-0/s526x395/14729198_1215187471887063_2861022715050595217_n.jpg?oh=588348d85735a1484d3915f8489b907c&oe=58D32E5A

Kasli na rust a pouzivej jazyk D :D.
http://mir.rocks
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html

Proc nepouzit C++, např. knihovny Armadillo či Eigen. Stále žiji s představou, když chci max speed, tak C či C++.

Tak kdyz ma C, C++ a Rust stejnej backend (LLVM), tak ten speedup je teoreticky ne? Nebo jinak - jaka vlastnost by delala z C/C++ takova dela v porovnani s jinym kompilovanym jazykem bez GC?

Muzou tam byt navic treba ruzne run-time testy, napr. meze poli, ukazatele, ...

Kdyz jsem kdysi cetl o vypujcenych ukazatelich v Rustu tak me treba pripadalo ze nektere veci budou muset testovat v run-time. Ale treba jsou chytri a vyresili to jinak... :-)

Potom podle semantiky jazyka nemusi nektere veci jit implementovat tak efektivne, treba dynamic dispatch. Nerikam ze tohle je pripad Rustu.

Dalsi co me napada je treba pattern matching. Kdybys to v C++ delal "rucne" tak tam treba vyuzijes nejakou znalost problemu a udelas to lip...

"Muzou tam byt navic treba ruzne run-time testy, napr. meze poli, ukazatele, ..." " ... tak me treba pripadalo ze nektere veci budou muset testovat v run-time... " " ... Potom podle semantiky jazyka nemusi nektere veci jit implementovat tak efektivne,... " " ... Dalsi co me napada je treba pattern matching. ..."

Typická ukázka předčasné optimalizace založené na dojmech. Víc k těm nesmyslům asi nemá cenu dodávat.

Tak jsem udelal maly testik, aby to nebylo mlaceni prazdne slamy, jednoducha smycka, sum square pro i od 0 do milionu, rust vs c, rustc vs clang, bez optimalizace c o rad rychlejsi, s optimalizaci O3 taky c rychlejsi, ale nechce se mi hrabat v rust deklaracich, abych zjistil presnejsi rozdily pro O3. Jen tak pro info, size rust exe codu 240kB, size c exe codu 8kB.

Mas prosim ty zdrojaky nekde na GitHubu (napriklad). Me by to docela zajimalo, jestli je to semanticky skutecne to stejny. Jinak velikost exe codu, to je pravda, na nejakem mikroradici si zatim dnesni verzi Rustu predstavit nedokazu.

Rust má podstatně větší standardní knihovnu než C a další věci co v C nejsou (např. panic! macro) a v základu linkuje staticky. Pokud opravdu potřebuješ minimální velikost, musíš si s tím vyhrát trochu víc (hledej bare metal rust). Jinak těžko říct cos tam proved, protože imho jenom smyčka by vyšla zhruba stejně rychlá i v Javě.

Co se velikosti binárka týče, https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html je pěkný čtení.
TL;DR: Rozebírá se tam velikost "Hello World" kde Rust má 650kB a C jen 8,5kB. Je tam něco o debugovacích symbolech (moc nevim co to je) - obsahuje jemalloc pro dynamické alokace ikdyž nejsou v programu, backtrace a jeho stringy ikdyž v programu není panic. Po odstranění dohodle je to na 113kB. Taky knihovny jsou linknutý staticky a ne dynamicky jako u C. Rust má nějaký závislosti na standardní C knihovně, linkuje je staticky, jakýmsi příkazem kompilátoru se dá linknout dynamicky a pak je Rust stejně velký jako C.

Tezko rict kam az ten optimalizator "vidi". "Moderni" C++ ma tu vyhodu, ze vsechno jsou jen sablony, ktere obsahuji pouze inline metody. Spojenim takovych sablon pak vznikne velice dlouhy kod, na kterem ze muze opimalizator vyradit. Dneska se ale daji podobnym zpusobem optimalizovat i non-inline funkce. Za urcitych okolnosti optimalizotor vi, ze po zavolani nejake jednoduche funkce zustanou registry nezmenene.

No, když Rust, C++, D a další budou kompilovat přes LLVM, pak se lišit moc nebudou a důležité pro volbu jazyka bude to, jak se v něm dělá. To je jednak syntax (každému vyhovuje jiná, někdo se nevzdá té céčkovské, někomu se líbí Rust) a pak (asi hlavně) práce s knihovnama.

A Rust je v tomhle dobrý (poučený z Javy, Pythonu, Nodejs, ....) a přes cargo nabízí snadnou práci s knihovnami (nevím proč tomu říkají crates).

V C/C++ už jsem nějaký rok nedělal, ale s knohovnama byl někdy problém. Hlavně s různými verzemi knihoven.

A co jako? Mám přesně opačnou zkušenost. Jestli má někdo potřebu se po naučení Javy vracet k C++, tak to ten jeho kód musí být teda pěkná "lahůdka". Raději bych to snad ani nechtěl vidět, natož tam muset něco modifikovat. A soudě dle vašich různých názorů zde v diskusích mám z vás pocit, že přestože "jste napsal hru", tak bych si k vám pro rady ohledně technik programování a softwarového inženýrství rozhodně nechodil.

http://250bpm.com/blog:4

zajímavý blogpost, i když asi ne se vším se dá úplně souhlasit. Nicméně jako námět na zamyšlení moc pěkné!

IMO ty nejstrašnější vlastnosti (třeba bordel v intech) C++ zdědilo právě od C.

A to je podle me i odpoved na to, proc se rika, ze Rust ma ambici nahradit C. C++ je C s pridanou hodnotou (a hromadou balastu) a +- se v nem porad da psat normalni C. Rust se snazi predefinovat "nastupce C" s minimem balastu a znalostmi z okolniho sveta, ktere autori maji.

Myslim, ze Linus to vysvetloval tim, ze C++ skryva pred programatorem alokaci pameti, coz muze byt v kernelu kontraproduktivni. Napr. diky implicitnim datovym konverzim zavolate metodu a pred jejim faktickym zavolanim si vytvorite hromadu docasnych objektu na stacku.

C a C++ maji "problem" v tom ze nerozlisuji mezi poiterem na stack a pointerem na heap. Snadno muzete na heapu vytvorit instanci, ktera ukazuje na stack vaseho vlakna a vsechno bude krasne fungovat dokud vase vlakno neumre. Takove chyby, jsou jen velice tezko odhalitelne. (I kdyz v C++ se daji udelat smart pointery, ktere neco takoveho nedovoli)

C++ nedělá žádné skryté alokace.

V originale Linus psal:

any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.

Nemluvi tedy o skrytych alokacich, ale o jazycich, ktere rady skryvaji veci jako je alokace, coz ma trochu jiny vyznam. Staci se zamyslet nad tim, proc vznikaji vyssi jazyky. Je to prave proto, aby skryvaly jednotlive nudne casti programu a nezatezovaly tim programatora. Kdyz tedy C++ nic neskryva, k cemu je dobre?

Takže ano, pokud napíšete std::string x = "ahoj", pak se tam alokuje paměť pro řetězec "ahoj".

Nejak na tom radku postradam explicitni alokaci pameti. Nebude to tim, ze ji C++ skryva?

C++ samo nic neskryva, skryva ji knihovna

Zrovna tak muzes v C napsat knihovnu kde budou skryte alokace...

C++ ti umoznuje jit na vyssi uroven abstrakce a skryt detaily kdyz chces, ale taky muzes zustat stejne low level jako v C.

Mel jsem na mysli neco takoveho:

#include <stdio.h>

class Foo
{
public:
    Foo(int x) {};
};

class Bar
{
public:
    Bar(Foo const &_f)
    : f(_f)
    {};
    Foo const& f;
    void print()
    {
        const void *p = &f;
        printf(" pointer: %p \n", p);
    }
};

int main()
{
    Bar *pf1 = new Bar(Foo(42));
    Bar *pf2 = new Bar(42);
    pf1->print();
    pf2->print();
    return 0;
}

Zavolam "new Bar(42);" a vubec si nevsimnu, se vlastne vykona "new Bar(Foo(42));" a mam na heapu instanci, ktera ukazuje na muj zasobnik.

PS: uz jsem v C++ dlouho nedelal, takze jestli je to blbost, tak me opravte.

Ja si treba myslim, ze C je na kernel lepsi z hlediska code-review a kontroly spravnosti kodu. C je 'jednodussi' jazyk - clovek si vystaci s par klicovymi slovy nekolika malo pravidly a jedna z nejslozitejsich veci je priorita operatoru. Naproti tomu v C++ clovek musi umet ruzne konstruktory, musi vedet ze jeden zapis (treba Foo a = b) muze volat ruzne konstruktory, v zavisloti na typu vyrazu b a tak podobne. Za mne je C++ sice casto lepsi nez C, ale je to bastl, takze na to aby clovek mohl _cist_ program se toho musi naucit mnohem vic nez v pripade C. Jine jazyky vyssi urovne se tomu vetsinou vyhly, protoze mely vyrazne konzistentnejsi vyvoj (ale existuji vyjimky jako treba PHP, to je imho jeste horsi bastl).

Ekvivalentní kód v C++ používající šablony, lambdy a inline funkce je obvykle o dost srozumitelnější.

To je hezke pri normalnim vyvoji, v pripade jadra to muze byt zasadni nevyhoda, protoze na jednu stranu ziskate sice srozumitelnejsi kod, ale zase ztracite predstavu o tom, jak dany kod bude vypadat po prelozeni do assembleru/stro­joveho kodu.