Názory k článku Rust: programovací jazyk do aut, vlaků a letadel

BoneFlute: "Copak C/C++ je?" To je narážka na ten zneužívaný termín, který sem použil, nebo si tím myslel fakt něco jiného? Zdejší diskuze je pro mne dost nepřehledná, může být nepochopení.

@Calculon psal, že Rust není vhodný pro mission/safety critical systémy. Já na to reagoval, že to C/C++ na to také vhodný není a nikdy nebude. Tedy jen jsem ve zkratce oponoval, že se Rustu (opět) vyčítá něco nefér.

Tady se ukazuje, jak vzniká nedorozumění. Já pochopil to jako že narážíš na výraz co to je "C/C++" a tím odsouváš pozornost na ten termín, který je pro někoho jak red flag. A tys to myslel úplně jinak. Promiň tedy. A máš pravdu, C a C++ není z tohoto, kromě historického důvodu, moc vhodné. To byla a je Ada a SPARK. Rust už radši nechávám stranou, rozhodně se na to ale hodí víc než C/C++.

3. 11. 2023, 15:10 editováno autorem komentáře

Ovšem použití SPARKu se dost prodraží, proto se používá jen když opravdu není zbytí. Proto se ostatně začaly prozkoumávat jiné přístupy statických garancí správnosti, akorát se ukázalo, že i ty jsou pro mnohé příliš složité.

A to ako dostavate v praci zadanie? Toto mi tu urob. Mame zakupeny kompilator pre C/C++ aj nejake kniznice, mame build prostredie a kazdy to tu ovlada ale vies co, kludne to urob v Zig-u tomu tu nikto nerozumie to bude super.
Ja som velky fanusik Zig-u ale to co pisete mi pride z pohladu zamestnaneho programatora ako nezmysel.

Já dělám na kontrakt a používá se jazyk, který chce klient nebo na kterém se shodne celý team, když se jedná o nový projekt.

Mluvil jsem ale hlavně o komunitě kolem jazyků C++ a Rust, to neustálé přesvědčování jednoho či druhého co je lepší nebo horší, je to unavující...

Asi zalezi co myslite v tej 'klasickej'. Zalezi kto kde nakupuje, napriklad tu mate Visa card s Javou:
https://www.alibaba.com/product-detail/CR80-JCOP-J3D145-Java-Bank-Card_1600739096024.html

No nazvat to ze je z Javou je dost prehnane. Je to skor Byte-code interpreter z istou mini-mnozinou API.

Oproti tomu je aj BBC:Micro z micropythonom superpocitac.

Ale na Androide ziadna JVM nebezi. Pozrite si Android Runtime(ART) pripadne starsi Dalvik (https://source.android.com/docs/core/runtime).

To, že na Androidě není JVM je jen důkaz toho, jaký shit JVM vlastně je :)

Google si svoje nástroje optimalizoval pro tento účel, ale i tak to nestačí a stačí se podívat na Apple, jak hezky mu to funguje s normálním kompilovaným jazykem.

31. 10. 2023, 12:12 editováno autorem komentáře

Na to ze ten shit pohana miliony komercnych rieseni ste dali celkom odvazne tvrdenie.
To ze sa napriek tomu ze sa to kompiluje do nativneho kodu Google rozhodol pre pouzitie Javy skor svedci o tom ze bol presvedceny ze C/C++ je shit. Ale kazdy to moze vidiet inac.

Podotýkám, že se nevyjadřuji přímo k Javě/JVM, ale obecně to, že je něco krám opravdu -- bohužel -- ještě neznamený, že to nemůže pohánět miliony, i stovky milionů, komerčních řešení. Nebylo by to zdaleka poprvé a skoro určitě ani ne naposledy.

No, Android používá jiný bytecode (více tříd v jednom souboru, register-based namísto stack-based). Ale jinak to je v podstatě Java. Je to založené na OpenJDK (od verze Nougat; předtím používali Apache Harmony). Samozřejmě to kvůli jinému bytecode musí používat jinou JVM. (Možná není korektní tomu říkat JVM, když používá jiný bytecode.)
Jiný bytecode má nejspíš hlavně historický význam. Asi bude obvykle menší (nejsem si jist, jestli na tom dnes opravdu záleží, ale OK), a asi v době interpretace byl rychlejší (JIT přišla ve verzi 2.2 Froyo, AOT v 5.0 Lollipop, resp. experimentálně už v 4.4 KitKat), ale dnes se používá nejspíš hlavně ze setrvačnosti.

Jiný bytecode byl politickou resp. právnickou nutností. Protože Androidí aplikace běží na mobilních zařízeních a pro ty není (tedy nebyla) k dispozici Java SE (SE=Standard Edition). Pro tato zařízení je určena Java ME (Mobile Edition), jenže ta už není/nebyla zadarmo.

Takže pokud by Google postavil své řešení na ME, musel by za každé zařízení s Androidem a JVM platit Oraclu, což se jim samozřejmě nechtělo (navíc jak to zařídit u třetích stran).

Takže si museli udělat vlastní "JVM která z právního hlediska není JVM" a tedy i odlišný bajtkód. Byly kolem toho i žaloby (lze dohledat) mezi Oracle a Googlem, ale do podrobností tady jít nemůžu (jako ex-autor OpenJDK a IcedTea; tam to bylo taky na hraně).

Takže Dalvik může být v něčem rychlejší, ale to nikdy nebyl hlavní důvod jeho vzniku.

O právních sporech jsem něco slyšel, ale zjevně jsem neznal celý background. Díky za opravu/doplnění.

Oracle žaloval Google už jen za to, jak se jmenujou některé funkce a jakou mají signaturu (parametry a návratovou hodnotu). Bylo to celkem nechutné abych se přiznal.

Vzdyt se spekulovalo ze kup SUNu byl hlavne kvuli tomuto. Oracle vypada jako patentovy troll.

Nevypada. On je.

Nastastie, narozdiel od Javy, a Mysql a Openoffice inu licenciu.

Jakto? V unsafe bloku mohu přece najednou porušit úplně všechno, ne?

Nebo tam je možnost granulárně povolit race condition, ale vyhnout se nepovoleným přístupům do paměti?

Jak píšu níže, třeba borrow checker funguje i v unsafe.

A je zrovna krásná ukázka toho, jak se to má dělat. Každý Unsafe je dokumentovaný a u každého je reasoning proč je to sound. Unsafe by default jazyky tady v porovnání fakt neobstojí.

> Každý Unsafe je dokumentovaný a u každého je reasoning proč je to sound.

Pokud by se tomu dalo věřit, tak by to bylo hezké. Jenže právě point Rustu je, že na lidi není moc spoleh a měl by to kontrolovat kompilátor, ne?

Ne, pointa je množství unsafe snížit na naprosto nutné minimum (i když programů které unsafe nemají vůbec je dost). Kontrolovat pár unsafe bloků na soundness je rozhodně snazší než kontrolovat kvůli tomu celý program včetně ne jedné, dvou, ale všech závislostí.

A opět, i Unsafe v Rustu je pořád bezpečnější než to samé v C++.

Nikdy nezapomenu na situaci, kdy se v C++ upstream jedné námi linkované knihovny rozhodl v nové verzi zahodit thread safety. Nikdo si toho nevšiml, kompilace na nové verzi debianu proběhla v pohodě, pak nám to v produkci začalo padat. Debugging byla opravdu radost. V Rustu se taková věc prostě nezkompiluje.

31. 10. 2023, 19:24 editováno autorem komentáře

Tak on v podstatě každý program používá nějaký unsafe kód. I hello world v libovolném jazyce. Někdy je unsafe skryt v kompilátoru, někdy ve standardní knihovně, často v obojím.

Tím nechci říct, že na tom nezáleží. Lze se snažit množství unsafe kódu redukovat, a ten, co zůstane, co nejlépe prověřit. A Rust oproti Cčku nabízí zajímavý posun.

Přesně to jsem měl nutkání napsat.

Jenže safety není úplně lokální vlastnost. Chybu lze zanést i tím, že safe kód poruší nějaký invariant, na který unsafe kód spoléhal. Takže nestačí pečlivě pročíst jen unsafe bloky.

Je pravda, že k posouzení unsafe je někdy potřeba posoudit i část kódu okolo. Ale pokud to není špagetový kód, stačí posuzovat celkem jasně omezený rozsah kódu.

Rozdíl mezi zaručeným (to Rust není) a mající víc záruk (to Rust má)?

Něco takového? https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=770005eaed00475037695723393eec07

Dá se to ještě zlepšit dalším kontejnerem a hozením BTreeSet - u do inner + nějaké pocné funkce na tvorbu, ale… Nevidím problém?

V principu ano. Nevýhodou je, že součástí každého itemu je ukazatel na celou tabulku. Každý item má 16 bajtů na 64-bitové architektuře.

Pokud by itemů bylo do 2^16, tak by měla stačit velikost itemu 2 bajty.

U Idrisu není bohužel moc dobrá dynamika, pořád to je víceméně one man show, ale člověk nikdy neví. Přinejmenším hezky prošlapal cestu.

undefined_behavior {
    unsafe {
        int main(int argc, char *argv[]) {

        }
    }
}

31. 10. 2023, 16:16 editováno autorem komentáře

Já bych hlavně viděl trochu filosofický rozdíl. Je to jazyk, co poskytuje mocné nástroje, které jsou náročné na naučení (a tím nemyslím různé pasti)? Nebo je jednoduše pochopitelný i pro začátečníky, ale vyžaduje víc dělničiny?

Moje kratší zkušenost s Rustem je taková, že když už kompilátor konečně kód akceptuje a zkompiluje, program/změna obvykle na první pokus běží. S C/C++ obvykle bojuji, abych vychytal paměťové "pasti", do kterých vždy spadnu, a program nekolaboval. Takže z mého pohledu je Rust pro non-seasoned céčkaře přívětivější. Píše se mi v něm skoro jako v javě (až na hlídání borrowcheckeru), high-level struktury (mapy, množiny, atd.), funkcionální zápis ala javovské streamy, oproti javě užitečné návratové tuples. Vlastně featury javy v posledních letech (match/switch, var) míří stejným směrem, takže Rust byl ještě higher-level. A zkompilovaný výsledek běží daleko rychleji a úsporněji.

Další obrovská výhoda je z mého pohledu snadný vývoj i na windows. Jenom rozchodit kompletní kompilační chain pro C je pro linuxového občascéčkaře docela boj. Ve win Rustu stačí spustit binárku rustup, stáhnout windowsí Ideu a do ní (bohužel již deprecated) rustí plugin. A možná by si ten plugin i spustil rustup sám :-)

Dělal jsem WASAPI Exclusive JNI DLL pro javasound https://github.com/pavhofman/csjsound-wasapi a bez Rustu bych se do toho vůbec nepustil. V Rustu to šlo docela pohodlně, generování DLL byly dva řádky v Cargo.toml. Samozřejmě jsem poté postupně měsíce ladil problémy nahlášené uživateli, ale to se týkalo hlavně korektního volání API WASAPI a víceméně nesouviselo s Rustem, fungující základ (včetně komunikace mezi několika vlákny) byl hotový za pár dnů.

Jako ano, je to asi hlavně otázka úhlu pohledu. Třeba z hlediska správy paměti Go půjde do úplně jiné kategorie (spíše vedle Javy než C/C++/Rust). A Rust je dost specifický na úrovni kódu, ale za běhu odpovídá správa paměti C/C++.

Rust umožňuje dost low-level věcí, často ale (narozdíl od C a částečně i C++) se statickou kontrolou. A řekl bych, že Linusovi Torvaldsovi se Rust zdál blíž C než C++…

Jo, v tomhle kontextu jsem myslela "označí mi to IDE / editor" :)

Tak operace move IIUC bez optimalizací znamená, že dojde ke kopii, a data na původním místě se již nemají používat. S optimalizacemi to může znamenat, že data zůstanou na původním místě, ale ne vždy je to korektní – pokud se na původním může paměť uvolnit příliš brzy (nebo nemůže, ale kompilátor si to nezvládne odvodit), je potřeba kopírovat.

Tady se imo rozchází terminologie.
Rust rozlišuje "Copy" (aplikovatelné pro typy u kterých se dá bezpečně udělat bitová kopie jako třeba primitivní typy) a "Clone".

Z pohledu Rustu C++ by default neprovádí Copy, ale Clone. Což je věc která se musí v Rustu dělat explicitně.

Jediná výjimka z "move everything" jsou právě proměnné implementující Copy, kde je možné poslat funkci kopii bez nějakého většího výkonnostního dopadu.

Jedna z výhod je, že Rust defaultuje k výkonnější variantě. Clone musí být explicitní a je víc vidět kde se duplikují data.

1. 11. 2023, 12:20 editováno autorem komentáře

Zrovna std::move() je v C++ docela bastl. Ono to udělá move jen v případě, že má objekt move construktor, není konstantní a nemá nějaké konstantní membery (respektive všechno v hierarchii dědičnosti musí být nekonstantní a mít move constructory). Jinak to tiše fallbackne na copy. Takže když vidím v C++ zdrojáku std::move(), nevím vlastně nic. Může to udělat move i copy. To má hodně daleko k dobrému řešení, je na tom hodně vidět, že move sémantika byla dolepená až v C++11.

ano, std::move() je ve skutečnosti jen povolení k přesunu, přesun řeší move constructor.

Pokud ti někdo dodal konstantní objekt, pak k tomu má asi důvod, asi nechce, abys mu ho ukradl. To je smysl const objektu.

Dokážu si představit rozumný scéář pro přesun konstantního objektu :
Dostanu nějaký objekt. U sebe ve funkci ho nechci měnit, jen číst. Takže dává smysl ho mít jako const, abych si ho náhodou neupravil.
A pak ho chci vrátit nebo poslat někam dál a už s ním nic dalšího nedělat. Tam zase dává smysl ho movnout.

A pak je tu problém, jestli nějaký typ dostane defaultní move, nebo jen copy. Když mám nějakého nepřesunutelného membera, tak se zbytek taky kopíruje, nebo se kopíruje jen to, co nejde přesunout? Přiznám se, že z hlavy nevím a smysl dávají obě možnosti. Takže je to další pravidlo k naučení.

1. 11. 2023, 13:29 editováno autorem komentáře

> U sebe ve funkci ho nechci měnit, jen číst. Takže dává smysl ho mít jako const, abych si ho náhodou neupravil.

Nikdo ti nebrání si to aliasovat na const ref a s tím pracovat, ale často se to nevidí (s výjimkou nějakých lambd)

Pokud ti vadí defaultní chování některých memberů, nadefinuj si u objektu vlastní move constructor a tam si zadefinuj způsob, jak se má objekt přesouvat a jak má naložit s konstantnímy membery. Nemusí pak kopírovat celý objekt, ale jen ty konstantní membery.

U některých objektů nelze kopírovat ani přesouvat, například std::mutex. Tam pak je nutné oba konstruktory napsat vlastní... nebo objekt vytvářet dynamicky a použít unique_ptr nebo shared_ptr.

Jasně že to umím obejít. A není to žádný zásadní problém. Ale jde mi o to, že čistý návrh by dával smysl trochu jinak.

Tím, že si vytvořím alias si nezavřu přístup k původnímu nekonstantnímu objektu. A stále na něj omylem můžu nějak hrábnout. Leda že bych udělal alias se stejným jménem v nějakém vnořeném bloku.

Problém s move je, že se používá hlavně k relokaci tj move+destroy. Relokace const objektu (ne const reference) je naprosto rozumná operace. Move, kdy mi vykuchané zbytky zůstávají pro nějaké pozdější použití, je vlastně dost obskurní věc, bez které bych se dokázal i obejít.

A spousta věcí je ještě lépe relokovatelná než jen movnutelná, třeba ten unique_ptr.

1. 11. 2023, 14:19 editováno autorem komentáře

Napsání move konstruktoru není špinavý návrh. Je to legální technika právě pro tyhle případy

Jako programátor mi trochu nesedí přístup "omylem hrábnout". Já nepíšu programy omylem, kód je výsledkem nějaké analýzy.

No mně by se taky líbilo, kdybych nikdy nedělal chyby, ale žijeme v reálném světě. Programátor, který si myslí, že se celkem běžně nemýlí je nebezpečný sobě i okolí.

A že je move v současné podobě dost omezené si uvědomuje i dost lidí z c++ komise. Proto se snaží standardizovat tu relokaci, protože takový unique_ptr nebo vector relokujete pomocí jednoduchého memcpy, ale standardní move je nepříjemně složitější kvůli oddělené destrukci.

Tak to nevím jak to chtějí řešit. Pokud programátor v C++ má pořád mít právo vybrat si, zda objekt bude alokován dynamicky nebo na "staticky" (na zásobníku), tak tam moc prostoru na vylepšení není.

Taky moc nevím, jak udělat move v C++ lépe, protože je potřeba zachovat zpětnou kompatibilitu, takže move sémantika v C++ je takový kočkopes.

Rust tohle historické dědictví nemá a řeší to velmi elegantně. Move je default, pokud nezavolám explicitně clone(), provede se move a ne copy. Move je destructible, po přesunutí objektu původní objekt zaniká a nejde použít (hlídá to borrow checker). Move je možné udělat na všech objektech jako memcpy, v Rustu neexistuje objekt, který by move nepodporoval nebo se musel dělat nějak složitěji než pomocí memcpy. Takhle definovaný move hodně zjednodušuje práci překladači i vývojáři.

> Takhle definovaný move hodně zjednodušuje práci překladači i vývojáři.
Zeptám se tedy, kde ten objekt žije? Zřejmě žije asi na heapu. To ne vždycky chci.

> Zeptám se tedy, kde ten objekt žije? Zřejmě žije asi na heapu. To ne vždycky chci.

V Rustu move nesouvisí se stackem nebo heapem. Je úplně jedno, jestli je objekt na stacku nebo heapu, protože ve chvíli, kdy můžu udělat move jako memcpy, můžu udělat move i mezi stackem a heapem a opačně. Samozřejmě do toho pak vstupuje lifetime objektů na stacku, ale to už je jiný koncept, to hlídá borrow checker.

Rozumím, takže nemohu ovlivnit kde bude objekt existovat, a musím se spolehnout na překladač a doufat, že vybere úložiště s ohledem na efektivitu kódu a bezpečnost zároveň

V Rustu můžeš objekt vytvořit kde chceš, na stacku nebo heapu a libovolně dělat move mezi stackem a heapem. Myslím, že nejlépe to osvětlí příklad:

struct A {
    name: String,
}

fn main() {
    // Instance A na heapu
    let a_heap = Box::new(A{name: String::from("John")});

    // Move A instance z heapu na stack
    let a_stack = *a_heap;

    // Vypise John
    println!("{}", a_stack.name);

    // Toto se nezkompiluje, protoze probehl destructive move:
    // error[E0382]: borrow of moved value: `*a_heap`
    println!("{}", a_heap.name);
}

jen reaguju čistě na vás, jako že nejsem znalec Rustu

šlo mi o to, jestli Rusr při přesunu objektu pri volání funkce sám se rozhodne, kam objekt přesune jestli na stack nebo do heapu, nebo to má v rukou programátor? dokážu si představit funkci, která dostane parametr a s ním spustí vlákno kam přesune ten parametr, tedy opravdu se musí přesouvat, protože původní lokace objektu se stane neplatnou

pak to funguje jako v c++ a žádný benefit tam nevidím.

Benefity move sémantiky v Rustu oproti C++ jsou docela zásadní:

Move je default. Když chci udělat kopii, musím to explicitně napsat.

Nemusím psát move konstruktor, všechny objekty mají move implicitně (kromě primitivních typů jako integery, tam move nedává smysl).

Move je destructible, původní objekt po move přestává existovat a hlídá to borrow checker. Nejde udělat chybu přístupu k objektu po move, jako v C++.

Move je interně implementován jako memcpy, žádné volání kódu objektu, tudíž vyšší výkon.

Neexistují obezličky jako std::move u kterých nikdo pořádně neví, jestli to move opravdu udělá, nebo ne. V Rustu je move možný vždy. Jasná, jednoduchá a výkonná implementace, ne jako ten přílepek v C++.

No on memcpy není vždy ok.

Typicky objekty, které mají vnitřní reference, ty je potřeba relokovat. Ale asi to nějak RUST dělá. Nicméně bych fakt na memcpy takhle jednoduše nesázel

Memcpy v Rustu je vždy OK. Rust nic relokovat nemusí, protože v Rustu nejde v objektu udělat vnitřní reference sám na sebe. Tím pádem ukazují všechny pointery ven z objektu a memcpy se používá na move všech objektů. Vývojář nemusí nic řešit, nemusí psát žádné move konstruktory, překladač má jednoduchou práci a nic rychlejšího než memcpy na move neexistuje.

vnitrni objekt ktery referencuje sveho vlasrnika aby s nim mohl komunikovat? nikdy jste nedelal?

aha, chapu

Vnitřní objekt ve smysu, že referencuje něco ze svého potomka nebo jiný sub-objekt v rámci objektu? Tohle jsem nedělal a nemám to v plánu, považuji to za špatný design. Ale chápu, že se to někomu takový nápad třeba může líbit.

Pokud máš potřebu dělat takové věci, není Rust jazyk pro tebe a nevyužiješ jeho výhody. Je škoda, že se na to nedokážeš podívat s nadhledem a apriori odmítáš všechno, co je jinak než v C++. Zrovna C++ je spíš příklad toho, jak by se to nemělo dělat, spousta špatného designu hlavně z historických důvodů, protože museli zachovat zpětnou kompatibilitu. Move sémantika je toho dobrým příkladem, v Rustu je vyřešená o světelné roky lépe, než v C++.

ty designy jsou dobry, ale Rust se k tomu nehodí

Nebudu vysvětlovat základy

Ty designy jsou překonané, hype OOP už naštěstí skončilo a dneska už se necpe všude. Rust na to jde jinak, nemá klasické OOP.

Starého psa novým kouskům nenaučíš, někdo prostě pokrok odmítá a zuby nehty se drž horších překonaných řešení. Bohužel to vede k horší kvalitě kódu s nižší bezpečností a výkonem.

5. 11. 2023, 00:11 editováno autorem komentáře

Nějaká motivace a existující implementace rozebírají v https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1144r7.html

Ještě ten rozdíl move vs relokace komplikuje věci jako předávání unique_ptr registrem, ale do tohohle se ten paper nepouštěl. Tohle je separátní problém.

na to zda se udela opravdu move je nejlepsi jednoducha pomocna tabulka,
ktera rika co vyjde kdyz je parametr nejaky typ a co do nej leze.
a z tabulky je videt, ze se move udela jen v poslednim pripade kdy funkce bere && a leze do ni taky prava reference.

T& & ---> T&
T& && ---> T&
T&& & ---> T&
T&& && ---> T&&

Asi ti úplně nerozumím, ale move funguje i v tomhle případě

void fn(Object x) {...}

{
Object y;
fn(std::move(y));
}

Žádné reference tam nejsou

podobne jako std::move(10), 10 je v tomto pripade rvalue (&&) takze move vraci zase rvalue (&&) stejne jako Objekt y;

1. 11. 2023, 21:21 editováno autorem komentáře

found this :-)

//Hello. I want my own local copy of your Widget that I will manipulate,
//but I don't want my changes to affect the one you have. I may or may not
//hold onto it for later, but that's none of your business.
void foo(Widget w);

//Hello. I want to take your Widget and play with it. It may be in a
//different state than when you gave it to me, but it'll still be yours
//when I'm finished. Trust me!
void foo(Widget& w);

//Hello. Can I see that Widget of yours? I don't want to mess with it;
//I just want to check something out on it. Read that one value from it,
//or observe what state it's in. I won't touch it and I won't keep it.
void foo(const Widget& w);

//Hello. Ooh, I like that Widget you have. You're not going to use it
//anymore, are you? Please just give it to me. Thank you! It's my
//responsibility now, so don't worry about it anymore, m'kay?
void foo(Widget&& w);

Bacha, "void foo(Widget&& w);" ten widget movnout může a nemusí. Může zůstat nezměněný, nebo v nejakém neznámém ale validním stavu.
Překladač musí předpokládat, že ten objekt můžeš dál používat, stačí ho vyresetovat.
A žádné zodpovědnosti to programátora taky nezbavuje. Nemusím ho řešit jen pokud bych ho nemusel řešit ani kdybych žádné foo nevolal. Pokud ten widget potřeboval nějaký manuální úklid, tak ho musím uklidit tak jak tak. Protože foo ten move může řešit třeba tak, že mi do toho widgetu nasype vnitřnosti nějakého jiného starého widgetu.

A "template<typename T> void foo( T && t )" je překvapivě úplně jiná potvora. To může být kterákoliv verze, kromě té první.

A teď mi řekněte, jak tohle učit, aby človek nemusel vytírat zbytky vybuchlých hlav :D

void foo(Widget&& w)
pokud do toho vleze w co je lvalue (&) tak se nemovne, ale kopiruje.
pokud do toho vleze w co je rvalue (&&) tak se movne.
prave podle tabulky.

Pokud je Widget normální typ, tak rozhodně ne. Pokud nemáte foo přetížené i pro normální reference, tak do toho lvalue ani nenacpete. Nezkompiluje se to.

Ta tabulka se používá jen u šablon, kde to && pak není rvalue reference ale říká se jí třeba "forwarding reference". Bez nějakého šablonového parametru nemáte odkud vzít druhou referenci ke spojení.

A ještě jedna věc. Ta tabulka říká, jestli dostanete rvalue referenci, ne jestli se opravdu udělá move (tedy jestli se někde v hlubinách zavolá move konstruktor nebo přiřazení). Rvalue reference je podmínka nutná, ale rozhodně ne dostačující.

1. 11. 2023, 23:26 editováno autorem komentáře

"template<typename T> void foo( T && t )"

tam není žádná věda, je třeba vidět, co je v T. Pokud je tam Obj &, pak funkce foo(Obj &) a pokud tam je Obj, pak foo(Obj &&).

Pokud volám tuto funkci a parametrem je proměnná, překladač za T dosadí referenci nebo const referenci. Pokud funkci volám s hodnotou, která vzniká jako dočasná instance, pak se za T dosadí přímo typ toho objektu, nebo může jít o návratovou hodnotu jiné funkce, i tam figuruje dočasná instance.

Ona rvalue reference se opravdu špatně chápe, ale přitom je to easy. Uvnitř funkce je to pořád reference a ta komunikace je pouze vně ve vztahu s volajícím. Rvalue reference pro volajícího znamená, že nesmí do parametru uvést lvalue referenci, tedy použít proměnnou jako parametr. Pokud tohle chce obejít, pak musí použít std::move(). a tím dává najevo, že proměnná ho od toho okamžiku nezajímá (jestli se přesune nebo ne je pak jiná věc, ale mě jako volajícího už nezajímá obsah a pokud se nepřesune, destruktor to vyčistí)

Pokud funkce nemá ani lvalue referenci, ani rvalue referenci, pak normálně konstruuju parametr konstruktorem. Ten mohu konstruovat jako kopii (copy constructor), nebo přesunem (move constructor) a to tak, že použiju std::move. Pokud objekt má move constructor, překladač ho upřednostní a tím je opět simulován přesun. Pokud ho nemá, použije se copy constructor. Pokud nemá ani copy constructor, dojde k chybě při překladu

Alex :
Ne, ta tabulka neříká, jestli se udělá move. Ta tabulka říká, jestli to co na první pohled vypadá jako rvalue reference je opravdu ona, nebo něco jiného. Je to jen jeden malý dílek z mozaiky.

A že je někde rvalue reference opravdu neznamená, že se ten move udělá. A jak psal ON, že nikde v dohledu nejsou žádné ampersandy neznamená, že se nemovuje. Ani std::move nemusí být někde v dohledu, stačí return nebo "foo( bar() )"

Nic ad hominem jsem tam nenapsal. Jenom to, že se chováš jako troll, ke každému článku o jazyku, který by snad někoho mohl zajímat, přicvakneš off topic vlákno o Leanu nebo Idrisu a ten jazyk, o kterém je článek, ideálně pomluvíš, aspoň náznakem.

A ten sock puppet samozřejmě byla taky poznámka o Tvém chování zde (dva účty v jedné diskusi). Nic k osobě.

Copak na to asi řekne Wavelet? :)

Není k tomu asi moc co napsat, koukám, že ty jeho urážky smazali a s tím i můj komentář. Označuje trolí a sám stále trolí. Dle mého tu nikdo neuráží Rust ani jeho komunitu. Dokonce se tu sešli vývojáři v C++ a níže debatují. Nic proti nikomu.

Mě rozhodně nevadí, když se nesouhlasí, ale tyhle výkřiky nemám rád. Pak čeká že na to někdo bude reagovat a když nic nepřichází nasází někde osobní útok.

Popravdě, několikrát sem se tu chytnul, to se stává, ale někdy je třeba couvnout zpět. Jsme tu docela individua. Opravdu neznamená že někomu nemusím dát za pravdu, i když s ním v 90% času nesouhlasím.

Jinak co se čeká v diskuzi o jazyku s typovým systémem jako má Rust? Haskell, Idris, Lean se přeci nabízejí pro srovnání. A že se někdo objevuje v diskuzích, kde se o tom vždy zmíní spíš souvisí s tím, že ty diskuze jsou o tématu, které ho zajímá, což jsou zjevně tyhle jazyky.

Jako blbce ze sebe občas udělám, ale tak systematicky po někom jít je opravdu výkon.

Už to nebudu rozmazávat, vzhledem k tomu, že ty jeho příspěvky už jsou pasé.

2. 11. 2023, 13:31 editováno autorem komentáře

Doufám, že se omluví aspoň tobě za “sockpuppet”.

Tak urážky anonyma na internetu mne netrápí, natož čekat omluvu. Jdeme dál. V právu asi není, když mu to smazali. Jen bych chtěl napsat, že jsem nic nehlásil, mě je fakt jedno kdo co píše v diskuzi -- sprostý nebyl jen trolí a uráží, a to se mne vůbec nedotklo.

Jo takhle, jako že můj účet je jeho? Vy jste tedy paranoidní. Můžem pokecat na Nyxu, tady to fakt nemá smysl. Když odfiltruju tu vaši paranoiu tak myslím, že bychom si v zásadě rozuměli :D

5. 11. 2023, 10:37 editováno autorem komentáře

S ohledem na to, kolik průšvihů s dost nepříjemnými následky už způsobily memory related chyby a s tím jak je Rust řeší (viz odkaz od Google), řekla bych že ano.

Ano, C++ se mění k nepoznání - z jedné strany ty změny chápu (Třeba snaha o nějakou memory safety ve formě smart pointerů), z druhé strany mi přijde že se do toho jazyku snaží nacpat jakoukoliv moderní věc co proletí kolem a je z toho „pejsek a kočička vařily dort“.

Jenže to první to nespasí - garance jsou mnohem slabší a "insecure by default" prostě pořád vede k chybám.

C++ má obrovskou setrvačnost. Ale čím dál tím častěji vidím u lidí i ve firmách úvahy na téma „OK, začínáme nový projekt, má smysl začít používat Rust?“ - viz MS, Google, Vivo. Všechny ty projekty by byly (Nebo opravdu byly) původně v C++.

Další místo kde vidím že se prosazuje dost slušně je právě webový backend, kde se začíná prát s Go. Zvlášť ve chvíli kdy je důležitá efektivita. https://hackernoon.com/how-using-aws-lambda-with-rust-saved-3x-the-cost-compared-to-using-python-or-net

Zrovna jsem dopsala jednoduchou microservice která řeší nginx forward outh pro OIDC. Celý kontejner zabírá 26 MB, při běhu je skoro pod rozlišovací schopnosti process monitoru.

Promiňte ale ten odkaz, to je přeci úplně zavádějící. Já Vám mohu nasdílet zase odkazy jak odchod z AWS nám ušetřil miliony. Jestli to bylo v Rustu nebo Pythonu je jedno. Já klidně budu psát v Rustu, dokonce i v Javě, když mne za to někdo bude platit a bude to intelektuálně zajímavé, ale takhle tlačit technologii mi přijde dětinské nebo lépe řečeno ideologické.

(Nicméně obdivuju jaké máte zaujetí, dokonce myslím, že jste mnohem vzdělanější než já, ale pochopte také nás přízemní dělníky :D)

Třeba APL je memory safe, to bych tlačil já ;)

2. 11. 2023, 20:02 editováno autorem komentáře

Tak každý jazyk má nadšence. Go, Python, JS... A zvlášť s tím jak se na jedné straně zvyšuje výkon a na druhé straně snižuje komplikovanost, je vidět slušné přesahy na jednu i na druhou stranu v doménách kde je ty technologie vidět. Python a Java na MCU, low level programovací jazyky na webu.

Osobně jsem se Rust začala učit v době kdy vycházel článek na Rootu, a ukázalo se to pro mě jako něco co mě opravdu baví a vyřešilo mi to spoustu problémů které mě na jiných technologiích štvaly. A teď to i relativně slušně vydělává :)

2. 11. 2023, 20:17 editováno autorem komentáře

"Osobně jsem se Rust začala učit v době kdy vycházel článek na Rootu".
Já bohužel také, příliš brzy :D V mé doméně to ale prostě bude minoritní jazyk i kdyby se prosadil sebevíce. Tak já si o víkendu otevřu, vedle Leanu, zapomenuté přiklady v Rustu :D. Pěkný večer.

2. 11. 2023, 20:30 editováno autorem komentáře

Já si otevřu pivo :)

Nevím, jestli tě to zajímá, ale Rust běhá celkem hezky v Postgresu (místo PL/…), včetně Amazon RDS. Dá se tam pracovat s composite types apod.

> "A potrbujeme vubec nahradu za C++? "
Určitě ano.
Já chci moderní jazyk, který bude pohodlný. Na situace, na které se hodilo C/C++, tedy rychlost, paměťovou úspornost, malost, předvídatelnost. Na ostatní situace máme jiné jazyky.

[BoneFlute]

A to je presne ono.

Pojem "moderni jazyk" je neco za co se da schovat uplne vsechno. Z mnoha diskuzi se ta fraze da prekladat napr. takto : "Sice presne nevim, co by to melo byt, ale musi to byt neco jineho, protoze to stavajici bytostne nesnasim, uz proto ze me do toho ti stari brontosauri nutili...." Nebo: "Musi se to ucit, premyslet u toho, vyvijet mentalni aktivita, a to je prace a to dneska uz absolutne neni IN." Nebo take: "Hlavne at je to klikaci a barevne!" Atpd.... Tedy vzor 'moderni .*' povazuji za dost neurcity pojem (tedy - pokud nejsi modni navrhar, popr. krejci/svadlena).

Souhlasim s tim, ze jsou situace, na ktere je nejaky konkretni jazyk vhodnejsi vic nez jiny. Kdyby jsi si mohl vybrat: V BASHi muzes vytvorit program pro spravu telefonich kontaktu. V Lue nepochybne take. V Jave take. Presto typuji ze hrabnete spis po Jave. Vidis - a ja bych uvazoval jako prvni o Lue.

Lopata - existuje spousta lopat. S kratsi, ci delsi nasadou, s operkou, naslapnikem, siroke, uzke, kovove, plastove... Vsechno je to lopata, kazda ma sve plusy a minusy a kazdemu cloveku se bude hodit jina a to casto i pro stejny typ cinnosti. Programovaci jazyk neni vice ani mene nez lopata programatora. Co je na co vhodne je dano mnoha faktory, vcetne povahy projektu, zadani, osobnich preferencich, a v neposledni rade hloubce znalosti daneho jazyka. A podle me takove generalizovani je uplne trochu nicem.

A tim se vracim ke sve otazce. Potrebujem v soucasne dobe nahradu za C++? Ja myslim, ze ne. Jazyku je obrovska spusta, presto C++ se drzi leta na prednich prickach oblibenosti. Nahrady uz jsou, a tam kde to vyvojari povazovali za ruzemne je uz pouzili. V ostanich pripadech jej z ruznych duvodu povazovali za rozumnou volbu.

> Potrebujem v soucasne dobe nahradu za C++?

Je tu filozofická otázka, co vlastně znamená náhrada za C++. C++ se uplatnilo v nějakých oblastech, ale v každé oblasti může mít potenciálně jinou náhradu. Někde to může být Java, někde Go, někde Rust. A někde zatím z různých důvodů vhodnou náhradu nemusí mít.

[Vít Šesták]

Jiste, to je pravda. Jen se zapomina faktor casu.

Setrvala pozice C++ v desitce nejoblibenejsich jazyku doklada, ze to nebude jen "nekde". A kdyz se podivame na soucasnou pozici treba Rustu a C++ a k tomu vezmu v uvahu jak dlouho tu ten jazyk je (a hype jaky kolem nej jeho komunita dela), pak se mi zda, ze bud na to jdou od zakladu spatne a nebo proste je zajem o nahradu za C++ celkem maly.

Jak moc v C++ vznikají nové projekty? Statistiky nemám, ale to by mohlo být z dlouhodobého hlediska důležitější než aktuální počty projektů. Nepopírám, že v C++ bude spousta projektů, které je potřeba dále udržovat, z hlediska nových projektů si ale nejsem tolik jistý.

[Vít Šesták]
Napriklad tady:
https://madnight.github.io/githut/#/pull_requests/2023/3

To je počet PRs, takže zahrnuje stávající projekty. Na tu otázku spíš odpovídá https://octoverse.github.com/2022/top-programming-languages

jen by mě zajímala metodika a data, Github tam moc sdílně nevypadá.
https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/ kreslí taky zajímavá čísla, ale za zdroje se mi platit úplně nechce.

[Kate]
Jasne, asi to neni uplne presne to na co se Vit ptal (nic lepsiho jsem po ruce nemel), ale zas na druhou stranu vychazim z toho ze PRs mas jak do novych tak do stavajicich projektu. I tak z tech dat od tebe vsude vidim C++ v prvni desitce. A minimalne jak muj, tak i tvuj prvni odkaz ukazuje na rostouci tendence u C++. Myslim, ze to lze jen tezko svest na pouhou udrzbou starych projektu - viz to moje upozorneni na faktor casu.

Částečně. Ono to může ukazovat nové projekty v C++, ale taky jen to, že stávající projekty získávají větší pozornost.

Předpokládám že to navíc bude ukazovat počet PR do projektu podle detekovaného jazyka projektu, což vede k paradoxům kdy třeba aktuálně probíhající přepis Fish shellu do Rustu počítá jako C++ :) To samé ze strany Pythonu matrix server Synapse, kde se do Rustu přepisují výkonově náročné části kódu, Python si s Rustem rozumí velmi dobře.

Pokud je ten můj první odkaz braný z nových repozitářů, byl by to lepší ukazatel.

3. 11. 2023, 08:45 editováno autorem komentáře

Trošku OT: sledujete někdo vývoj přepisu Fishe do Rustu? Přijde mi, že se to nějak divně zaseklo (Rust má už dlouho okolo 33%), zajímalo by mě, jestli by se tomu dalo nějak rozumně pomoci.

Zkus se zeptat Fabiana https://github.com/faho (případně na Mastodonu @faho@octodon­.social)

[Vít Šesták & Kate]
Ano to chapu, ale i kdyz vezmu v uvahu vase argumenty, jsem naprosto presvedceny, ze pokud by upadal zajem o dany jazyk - v nasem pripade C++, pak by jsme nutne museli pozorovat sestupnou tendenci behem let. V horizontu roku by nutne musely mit ty grafy drive ci pozdeji nezadrzitelnou a vyznamnou sestupnou tendenci. Podle me by prubeh oblibenosti jazyka mel mit vicemene hyperbolicky prubeh v case (setrvacnost). Nove projekty v danem jazyce by vznikaly v cim dal mensi mire. Mnoho dalsich by postupne upadalo v zapomeni, protoze by byly nahrazovany novymi (ci prepisovany), nebo by proste zastaravali. Nutne se to musi projevit i celkovem poctu PR do daneho jazyka. Ano to co pisete, by ten sesup krivky zadrzovalo, to ano, nemyslim, ze by to melo silu ten pad dlouhodobe zadrzet. Spis to ovlivni a zakulati tvar te krivky prubehu.

Jenze my tu zatim zadny vyznamny (radove v rocich) setrvaly upadek C++ nepozorujeme (a na druhou stranu ani stejne tak nepozrujeme nijak vyznamy vzestup Rustu - jakozto jazyka, ktery si klade za cil C++ nahradit). A rekl bych ze i grafy od Kate to vicemene podporuji.

10 let je v IT cely eon a ja z tech grafu vidim, ze pokud uz zajem o C++ vylozene nestoupa, pak je s relativne malymi vychylkami stabilni na vysoke urovni. :-)

3. 11. 2023, 11:04 editováno autorem komentáře

Zrovna tabulka "Growth in programming languages 2021 - 2022"

Additionally, Rust saw a more than 50% increase in its community, driven in part by its security and reliability. And Python continued to see gains in its usage across GitHub with a 22.5% year-over-year increase driven, in part, by its utility in data science and machine learning.

C v té tabulce je (to by vysvětlil rostoucí zájem o embedded), C++ chybí.

Celkem nečekám že by někdo začal přepisovat stávající obří C / C++ projekty. V jednom z mých bývalých zaméstnání jsme měli v C++ celý webový backend, tuna starého kódu, a fakt si nedovedu představit že by někdo v brzké době investoval čas a peníze do rewrite. Je to performance critical kód, Go nebo Rust by tomu slušely, někdo tehdy navrhoval i Clojure, což by taky byla zajímavá volba, ale ten čas prostě nikdo nezaplatí. Tak se šlo cestou postupných vylepšování toho co je.

S přibývajícím množstvím vývojářů a nutností udržovat stávající projekty bude zákonitě počet C++ vývojářů přinejhorším stagnovat, nejspíš pozvolna růst. Nikdo nečeká že C++ zanikne. Vždyť se drží i jiné jazyky, které měly historicky mnohem menší podíl. (Object Pascal, Visual Basic…). Pochybuju že by mnoho lidí volilo Object Pascal pro novou desktop app, ale zároveň pochybuju že Ghisler přepíše Total Commander třeba do Pythonu.

Co je místy vidět jsou přepisy dílčích knihoven (Windows, Curl přidávající možnost používat Rustí http / TLS knihovny jako backend, Android) a kód v nových OS (Fuchsia, Vivo BlueOS)

Zajímavý je zároveň pohled na GTK / Gnome ekosystém, kde je Rust celkem běžná volba pro nové aplikace.

[Kate]
Ale, prosim te...

50% narust bez uvedeni kontextu vsech ostatnich vyznamnych jazyku muze klidne znamenat, ze ke vsem ctyrem stavajicim projektum pribyli dva nove (kdyz to trochu prezenu). Podobne statisticke ukazatele pouzivalo PR oddeleni ODS, aby presvedcilo sve volice jak skvele si ODS vede. Jenze to byla fabulace a skutecnost byla pohledem obecnejsich statistik diametralne odlisna.

Samotny Rust se nedostal do prvni desitky ani v jednom z tech grafu a jediny graf co mame v teto diskuzi momentalne k dispozici, kde lze urcovat v kontextu ostanich jazyku je ten Gihub2, kde se nacahzi nekde na spodu prvnich 20 oblibenych jazyku a jen velmi mirne a pozvolna roste aspon podle PR

Ja jsem ve svem predchozim prispevku ani v nejmensim nenaznacil jakoukoliv predikci, kde by jazyk C++ mel skoncit ve svem pripadnem padu v oblibenosti. Natoz vubec zaniknout. Naopak predpokladam, ze by graf znazornujici jeho oblibenost mel mit hyperbolicky tvar. Jak znamo Hyperbola jde od nekonecna do nekonecna. Osobne predpokladam, ze by to vypadalo takto: bude v nejakem bode zacinat a prudce klesat, postupne se bude pad zpomalovat a nakonec se ustali nekde na spodu prvni dvacitky oblibenych jazyku - coz maji prave na svedomi projekty ktere bude (lhostejno z jakeho duvodu) nutno udrzovat a nadsenci. Mohu se samozrejme zmylit v rychlosti padu oblibenosti, a pak se bude tvar krivky mene strmy. V kazdem pripade to nebude (s privrenim oci) rovna primka vicemene soubezna s casovou osou.

Ja osobne si vubec netroufam rict, jak velky vliv by na to vsechno mohl mit stoupajici pocet vyvojaru, jednak na to nemam relevantni data a jednak tusim, ze to rozlozeni novych sil bude silne nelinearni a tezko predikovatelne. Klidne tak muzeme vysvetlovat treba ten zajem o Go, nebo JavaScript (zrona webove zazivaji velky boom, takze se da predpokladat, ze se budou nove sily soustredit hodne tam)

[Kate]
Musim se omluvit za jeden svuj omyl.
Nevim jak, ale nejak mi uniklo, ze ty statisky oblibenosti co jsi postovala zobrazuji vic pozic, vsiml jsem si toho az ted.

Kde mezi C++ a Rustem je nejakych 8% rozdil. Jenze mi to nesedi pak s temi PR.

Asi ma nakonec pravdu Churchill :(

3. 11. 2023, 15:10 editováno autorem komentáře

Já si myslím, že vzestup Rustu je docela na začátku.

Stáří Rustu – otázka úhlu pohledu. Začátky lze sledovat již v roce 2006, oficiální oznámení 2010, verze 1.0 až v roce 2015.

Rychlost adopce – ono dost záleží. Teoreticky jazyku stačí kompilátor, prakticky se hodí vývojářské nástroje a knihovny. V případě knihoven jednak záleží na oblasti použití a jednak na tom, jak moc je ten jazyk schopen využít knihovny z jiného jazyka, což může usnadnit nástup. Například Kotlin/JVM má celkem dobrou interoperabilitu a Javou (chybí tam hlavně informace o nullability, ale i s tím lze pracovat), takže lze použít Javové knihovny. V Rustu patrně půjde použít Cčkové knihovny, ale prakticky to znamená nejspíš napsat wrapper, který pořeší lifetimes, safety apod. To plyne z návrhu jazyka. Ano, šlo by ten jazyk udělat konzervativněji, aby lépe interoperoval s C nebo C++, ale tím by se vytratily i výhody.

Potkal jsem různé vznikající jazyky. Mnoho z nich umělo skvělé věci. Chvilku jsem se jim věnoval - ale opatrně: Napíšu v tom něco zajímavějšího a rozsáhlejšího, a co budu dělat, když autor ten jazyk zařízne? A taky že jo.

A ona je to spojitá nádoba. Jazyk potřebuje adoptery, kteří ten jazyk podpoří tím, že ho budou používat. Jenže vývojáři se bojí používat jazyk, který nemá slibnou budoucnost.

Dle mého odhadu, tuto fázi má Rust úspěšně za sebou. Dokonce snad má za sebou i fázi, řekněme, "jazyka na okraji zájmu", kam třeba patří Haskell, Idris, Crystal, D, etc.

Řekl bych, že je dostatečně zabydlen. A nyní záleží jak moc velký koláč si urve. Což je ale zase na druhou stranu otázka, jestli mě to trápí. Maximálně když bych sháněl vývojáře.

Maximálně když bych sháněl vývojáře.

Pokud ti nevadí remote, sehnat podle mé zkušenosti není problém :)

Píšu si: "Až budeš shánět Rust vývojáře, @Kate nějaké zná."

Měnila jsem práci, takže nemám přístup ke kandidátům co se mi hlásili do teamu. Ale jinak jo, rozhodně jich pár znám, jen ne v ČR. Tady bude fajn ten Pavlixův nápad, zajít na pivo v Praze by se hodilo.