Budoucnost Rust v embedded světě

[Longin]

Jak vnímáte budoucnost Rust v embedded světě v horizontu 5-10-20 let? Vytlačí C/C++ nebo oboje?
Má smysl se ho učit u embedded vývojáře, co ovládá jenom C a Python a přemýšlí kam se posunout?

[Reklama]

[RDa]

Spis bych to videl na posun k C++.

Nemusis pouzivat vsechny frikulinske featury C++, ale nektere veci dost potesi a zprehledni vetsi codebase.

Viz arduino - jako neni to reference pro embedded, ale myslim ze jim C++ dost pomohlo redukovat kolize v libkach/nazvech funkci skrze namespaces a tridy.

[kate]

Zatím těžko říct, C++ pořád hraje hlavní roli, ale některé firmy už u po Rustu v tomhle ohledu dost pokukují, nebo ho přímo testují. Třeba Espressif v něm zdá se vidí dost budoucnost. V ČR pak myslím ještě embedded Rust dělá Braiinz.

Osobně se embedded věnuju jen občas jako hobby, ale musím říct že s https://embassy.dev/ frameworkem se pracuje opravdu dobře. Občas ale člověk narazí na limity ještě docela malého ekosystému. C knihovny se dají najít prakticky na cokoliv. V Rustu občas nezbyde než použít FFI, nebo si to napsat ručně.

[snugar_i]

Jak vnímáte budoucnost Rust v embedded světě v horizontu 5-10-20 let? Vytlačí C/C++ nebo oboje?
Má smysl se ho učit u embedded vývojáře, co ovládá jenom C a Python a přemýšlí kam se posunout?

Řekl bych, že smysl to mít může už z toho důvodu, že tě to donutí trochu jinak myslet a něco z toho pak třeba použiješ i v tom C/Pythonu. Jestli by tě to dokázalo uživit je jiná otázka, a tam po pravdě netuším.

[kate]

Jak vnímáte budoucnost Rust v embedded světě v horizontu 5-10-20 let? Vytlačí C/C++ nebo oboje?
Má smysl se ho učit u embedded vývojáře, co ovládá jenom C a Python a přemýšlí kam se posunout?

Řekl bych, že smysl to mít může už z toho důvodu, že tě to donutí trochu jinak myslet a něco z toho pak třeba použiješ i v tom C/Pythonu. Jestli by tě to dokázalo uživit je jiná otázka, a tam po pravdě netuším.

Práci jako embedded Rust dev už každopádně sehnat jde. Přinejmenším vím že něco poptával Microsoft pro vývoj firmware, v Čechách ještě cryptocurrency firmy - braiins, a nějakou dobu zpátky jsem dostávala zprávy od headhunterů z tuším Satoshi labs, ale blockchain technologie mě moc neberou.

[Reklama]

[anonacct]

Podle diskuze tady to asi není takové terno...

Ale rust budoucnost v embedded světě určitě má v nějakém rozsahu třeba 10 let, otázka jen je, jestli ty výsledné binárky nebudou trochu nabobtnané oproti třeba C++.

[RDa]

Ono to neni zadne terno a nikdy nebude - RUST ma vyhody pro klasicke programovani, kde to dela kdejaky lojza ktery si nevidi za spicku nosu - resp. nema vubec poneti o implementacnich detailech a jak cpu/os funguje, ale ma/musi neco kodit. Takze ho pak doslova zachranuje prekladac, aby mu to vratil ze takhle ne kamo.

U embedded veci a hlavne tech, ktere jsou opravdu kriticke existuji coding practices / rules - napr. https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code - aby se dalo tvorit i s tim co mame (tj s C), klidne si najdete videa na YT ktere se tohoto tykaji.. nektere jsou usmevne, kdyz autori zjisti nejakou novinku protoze tohle jim jako fakt nikdo predtim nerekl :D :D

Nemyslim si, ze ten hardcore embedded slevi ze svych standardu a presune zodpovednost z pravidel/lidi na pouhy prekladac. I v rustu jde napsat nesmyslny konstrukt (nekonecna rekurze) a proste to skonci padem ze dojde pamet.

A dalsi vec proc RUST v embedded ne: typicky mensi embedded zarizeni ma omezenou pamet a malloc/free tam neni bezna vec, takze ona ochrana kterou RUST prinasi je k nicemu. A jak uz bylo zmineno - existuji urcite knihovny ktere jsou hlavne v C, treba na hw akceleratory nebo nejakou overenou sw funkcionalitu. To zas musite includovat a jste zpet v klasice.

[Longin]

Tak dneska se bohatě používají embedded zařízení, kde se dynamická alokace používá naprosto běžně.
Poslední roky třeba vnímám dost velký tlak v prosazování Zephyru, což je "RTOS" pro lidi z Linuxu, a podobných věcí, kde lidi nechtějí řešit low-level.
Takže ty critical věci můžou být časem fakt niché, protože startupy i větší komerce budou nasazovat tyhle záležitosti, protože budou na vývoj levnější a rychlejší.
Výsledek stejně musí projít kvalitou a testama a ty neřeší, jestli ten kód je psaný profesionálně v C/C++ nebo novátorsky v Rustu.

[snugar_i]

Navíc právě kvůli embedded existuje i no_std Rust (bez alokátoru apod.) a spousta knihoven má i no_std verzi

[BoneFlute]

otázka jen je, jestli ty výsledné binárky nebudou trochu nabobtnané oproti třeba C++.

Proč by měli být?

[linuxak]

U embedded veci a hlavne tech, ktere jsou opravdu kriticke existuji coding practices / rules - napr. https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code - aby se dalo tvorit i s tim co mame (tj s C)

Spoustu z toho řeší Rust tak nějak automaticky:

• Avoid complex flow constructs, such as goto - Rust nemá goto.
• Restrict the scope of data to the smallest possible - Rust má RAII, takže je to zajištěné automaticky. Ano, i C++ má RAII, ale v C to není.
• Check the return value of all non-void functions, or cast to void to indicate the return value is useless - Přesně tohle vynucuje v Rustu Result a je to věc, která je udělaná opravdu dobře a skvěle se s ní pracuje.
• Use the preprocessor only for header files and simple macros - Rust má Hygienic Macro, takže s použitím preprocesoru není problém.
• Limit pointer use to a single dereference, and do not use function pointers - To je kvůli memory-safety, autoři pravidla doufají, že když se bude používat jen jedna úroveň dereference, bude to programátor schopen udržet v hlavě a kód bude memory-safe (spoiler alert - nebude, ani tak nejsou programátoři schopni psát memory-safe kód). V Rustu to nemusím řešit, hlídá to za mě překladač.

Nemyslim si, ze ten hardcore embedded slevi ze svych standardu a presune zodpovednost z pravidel/lidi na pouhy prekladac.

Hardcore embedded svět taky pochopí, že když něco můžet dělat překladač, tak by to měl dělat překladač a ne člověk, protože překladač narozdíl od člověka chybu neudělá. Oni už to pochopili, jen transfer od C k něčemu více safe bude chvíli trvat.

A dalsi vec proc RUST v embedded ne: typicky mensi embedded zarizeni ma omezenou pamet a malloc/free tam neni bezna vec, takze ona ochrana kterou RUST prinasi je k nicemu.

Tak to je opravdu velké nepochopení, memory-unsafe kód jde samozřejmě napsat i bez malloc/free. Např. tento kód v C:

Kód: [Vybrat]

int main()
{
    int a[1] = {42};

    int i;
    for (i = 0; i < 2; ++i) {
        printf("%d\n", a[i]);
    }
   
    return 0;
}
je memory-unsafe a žádné malloc ani free tam není. Mimochodem je napsaný podle všech "Rules for Developing Safety-Critical Code", ničemu z toho neodporuje. Rust by to samozřejmě chytil.

[balkovic]

Jak vnímáte budoucnost Rust v embedded světě v horizontu 5-10-20 let? Vytlačí C/C++ nebo oboje?
Má smysl se ho učit u embedded vývojáře, co ovládá jenom C a Python a přemýšlí kam se posunout?

Minimálne na cvičenie sivej hmoty mozgovej a predchádzanie fachidiocii je to dobrý nástroj.  V Rust sa myslí trochu inak. Ja som robil roky embedded javu, o ktorej rôzni experti hovorili rôzne nepravdivé tvrdenia. Robilo sa v nej dobre.

[RDa]

Tak to je opravdu velké nepochopení, memory-unsafe kód jde samozřejmě napsat i bez malloc/free. Např. tento kód v C:

Kód: [Vybrat]

int main()
{
    int a[1] = {42};

    int i;
    for (i = 0; i < 2; ++i) {
        printf("%d\n", a[i]);
    }
   
    return 0;
}
je memory-unsafe a žádné malloc ani free tam není. Mimochodem je napsaný podle všech "Rules for Developing Safety-Critical Code", ničemu z toho neodporuje. Rust by to samozřejmě chytil.

Na tohle vam ale staci chytrejsi C prekladac, zrovna gcc-15 se v tomhle chova zvlastne, puvodni kod neukazuje zadnou chybu, ale pridanim printf("%d\n", a[2]); pred return si to zacne stezovat i na "undefined behavior" v ramci vaseho cyklu, v zavislosti na urovni optimalizace:

Kód: [Vybrat]

$ gcc -O0 -Wall -Warray-bounds=2 test.c -c -o test.obj


$ gcc -O1 -Wall -Warray-bounds=2 test.c -c -o test.obj
test.c: In function ‘main’:
test.c:9:9: warning: iteration 1 invokes undefined behavior [-Waggressive-loop-optimizations]
    9 |         printf("%d\n", a[i]);
      |         ^~~~~~~~~~~~~~~~~~~~
test.c:8:19: note: within this loop
    8 |     for (i = 0; i < 2; ++i) {
      |                 ~~^~~


$ gcc -O2 -Wall -Warray-bounds=2 test.c -c -o test.obj
test.c: In function ‘main’:
test.c:9:9: warning: iteration 1 invokes undefined behavior [-Waggressive-loop-optimizations]
    9 |         printf("%d\n", a[i]);
      |         ^~~~~~~~~~~~~~~~~~~~
test.c:8:19: note: within this loop
    8 |     for (i = 0; i < 2; ++i) {
      |                 ~~^~~
test.c:12:5: warning: array subscript 2 is above array bounds of ‘int[1]’ [-Warray-bounds=]
   12 |     printf("%d\n", a[2]);
      |     ^~~~~~~~~~~~~~~~~~~~
test.c:5:9: note: while referencing ‘a’
    5 |     int a[1] = {42};
      |         ^

Naimplementovat statickou kontrolu kodu, kdy se pro iterator ve for cyklu odvodi compile-time range by nemel byt probem, aby to chytlo tenhle pripad.

A pokud bude index odvozovan dynamicky (z uzivatelkskeho vstupu), tak to zachrani jedine runtime bounds check - ale to prijde s vykonnostnim omezenim. A stejne tak v safety critical kodu ten bounds check muzete pridat treba makrem, pokud nejste linej, pripadne pouzit C++ a pretizit [] operator a udelat si tam runtime kontrolu pri kazdem pristupu.

[linuxak]

Na tohle vam ale staci chytrejsi C prekladac

Ne to ani náhodou nestačí. Není to jen o bounds checking, ale hlavně o lifetime objektů. V tomto programu je undefined behavior, vrací se pointer na b proměnnou, která je out of scope a pak se vypíše její hodnota. Tohle není C překladač schopný odchytit, protože nezná lifetime objektů, na které ukazuje nějaký pointer. Rust to samozřejmě chytí, v Rustu se tento kód vůbec nepřeloží.

Kód: [Vybrat]

int *max(int *a, int *b)
{   
    return *a > *b ? a : b;
}

int* test(int *a)
{   
    int b = 11;
    return max(a, &b);
}

int main()
{
    int a = 10;

    printf("%d\n", *test(&a));

    return 0;
}


[Jožka Niemand]

Rust je IMHO možná náhrada za C++, nikoli za C. Jakožto embedded a low-level vývojáři mi Rust nepřináší žádné killer-features, jen mi svazuje ruce. Nemám rád jazyky, které mě chtějí školit a vodit za ručičku, svá dětská léta mám už dávno za sebou.
K příkladům, jež tu padly - když z jakéhokoli důvodu budu chtít znát mimo příslušný lexikální kontext absolutní adresu, na níž byla na zásobníku nějaká lokální proměnná, tak nechci, aby mi nějaký blbý překladač házel klacky pod nohy, protože mě považuje za vola. Potřebuji se soustředit na řešení svého problému, ne přemýšlet nad tím, jak přemluvit překladač, aby udělal to, co potřebuji.