Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Longin 01. 05. 2025, 20:00:02
-
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?
-
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.
-
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ě.
-
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.
-
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.
-
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++.
-
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.
-
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.
-
Navíc právě kvůli embedded existuje i no_std Rust (bez alokátoru apod.) a spousta knihoven má i no_std verzi
-
otázka jen je, jestli ty výsledné binárky nebudou trochu nabobtnané oproti třeba C++.
Proč by měli být?
-
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 (https://doc.rust-lang.org/rust-by-example/error/result.html) 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 (https://en.wikipedia.org/wiki/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:
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.
-
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.
-
Tak to je opravdu velké nepochopení, memory-unsafe kód jde samozřejmě napsat i bez malloc/free. Např. tento kód v C:
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:
$ 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.
-
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ží.
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;
}
-
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.
-
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.
A proto velké firmy hlásí, že největší počet problémových chyb byl právě z oblasti správy paměti, kde C neposkytuje žádné pomůcky.
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.
Adresu si klidně získejte i v Rustu, jen nesmí opustit funkci, ve které je platná. A za vola by Vás považovaly i bezpečnostní standardy jako MISRA C.
On ten Váš problém (máte praktický příklad?) se možná dá vyřešit přímým přístupem do paměti, ale tak nějak tím riskujete celkem velkou plejádu možných chyb. Od poškození zásobníku až po přístup do náhodné paměti a záhadné pády aplikace.
Rustí borrow checker je přísný a neodhalí všechno (jak ilegální, tak legální aplikace). Proto máme i unsafe, kde je povinností programátora zdokumentovat, proč je zrovna tento trik v pořádku, aby to při code review bylo naprosto zřejmé i ostatním.
Osobně jsem stejný projekt (průměrně komplikovaný firmware a rádiový protokol pro senzorovou síť) postupně napsal v C, C++ i Rustu a i přes přísnost jazyka je ten Rust nejlépe udržovatelný.
Samozřejmě existuje třeba demo scéna nebo triky z 80. let se samopřepisujícím kódem. Některé ty výsledky byly úžasné... ale do prostředí s garantovanou bezpečností se to prostě nehodí.
-
A proto velké firmy hlásí, že největší počet problémových chyb byl právě z oblasti správy paměti, kde C neposkytuje žádné pomůcky.
Stačí, aby velké firmy angažovaly zkušené profesionály za odpovídající peníze. Vyřešilo by to i další problémy.
Adresu si klidně získejte i v Rustu, jen nesmí opustit funkci, ve které je platná. A za vola by Vás považovaly i bezpečnostní standardy jako MISRA C.
Proto jsem napsal "mimo příslušný lexikální kontext" - tedy tím chci říci, že to adresu chci právě mít mimo tu funkci. MISRA je dlouhodobě terčem různé kritiky, to není žádný argument. Jestli to dává, nebo nedává smysl, to nejlépe posoudím já sám. Že si někdo neumí představit, k čemu by to mohlo být dobré, je jeho omezení, nikoli moje. Vybavuje se mi Horníček s Werichem: "H: Postavit loď na kopci? To je ale blbost! W: No, pravda, taky se mu tenkrát všichni blbci smáli."
On ten Váš problém (máte praktický příklad?) se možná dá vyřešit přímým přístupem do paměti, ale tak nějak tím riskujete celkem velkou plejádu možných chyb. Od poškození zásobníku až po přístup do náhodné paměti a záhadné pády aplikace.
Teď zrovna mě nenapadá, k čemu bych to využil. Ale život mě za ta léta naučil, že umí nastolovat situace, jež nevymyslí ani ta nejbujnější fantazie. Víte, já si velmi dobře uvědomuji, jaké chyby to může způsobit, to mi tu nemusíte vykládat. Stejně jako si uvědomuji, co se může stát, když v autě přejedu dvojitou plnou čáru. V naprosté většině situací to činit nebudu. Ale dovedu si představit i situace, kdy bych to udělal, zatímco kdyby tam bylo svodidlo, tak mám situaci výrazně komplikovanější.
-
Suhlasim s tym, ze v embedet svete Rust neprinasa ziadnu killer feature, lebo aj tak polka kodu bude unsafe (skusal som to).
Co sa tyka C++ tak pri malych projektoch je vdaka uniq_ptr takmer nemozne spravit chybu, ked sa clovek nesprava ako prasa.
Skor dufam, ze sa v embedet svete presadi Zig, na low-level veci, WASM a embedet ovela zuajimavejsia volba ako Rust alebo Go.
-
Suhlasim s tym, ze v embedet svete Rust neprinasa ziadnu killer feature, lebo aj tak polka kodu bude unsafe (skusal som to).
Tak to jsi dělal něco špatně, půlka kódu rozhodně nemusí být unsafe ani v embedded.
Co sa tyka C++ tak pri malych projektoch je vdaka uniq_ptr takmer nemozne spravit chybu
Ehm...
auto a = std::make_unique<int>(42);
auto b = std::move(a);
std::cout << *a; // NULL pointer dereference!
-
Stačí, aby velké firmy angažovaly zkušené profesionály za odpovídající peníze. Vyřešilo by to i další problémy.
Rozdíl mezi zkušeným profesionálem a nezkušeným začátečníkem je jen ve škodě, kterou jejich chyby způsobí. Začátečníka nikdo ke kritickým věcem bez dozoru nepustí.
I profíci dělají chyby. Dokonce i hloupé chyby. Taková Ariane nebo NASA by mohli vyprávět...
https://en.wikipedia.org/wiki/Ariane_flight_V88
https://cs.wikipedia.org/wiki/Mars_Climate_Orbiter#P%C5%99%C3%AD%C4%8Dina_ne%C3%BAsp%C4%9Bchu
A protože si složitost software a omylnost vývojářů umíme přiznat, tak máme od té doby různá povinná code review a povinné statické analýzy v překladači a mimo něj. I pro profíky.
MISRA je dlouhodobě terčem různé kritiky, to není žádný argument. Jestli to dává, nebo nedává smysl, to nejlépe posoudím já sám.
To si klidně posuzujte. U Vašich vlastních projektů.
Jenže u dlouhodobých věcí to taky musí někdo udržovat. A nemusí znát všechny Vaše triky. Nebo se může ten kód portovat na novou platformu, kde nějaký invariant přestane platit.
MISRA je terčem kritiky proto, že je zastaralá a zaseklá právě u starých překladačů a verzí jazyka. Že nereflektuje nové funkce jazyků a překladačů, které usnadňují práci a zachovávají (hlídají) bezpečnost.
Taky očekává programování v notepadu bez kontrol a proto vyžaduje (otravný) styl psaní, který eliminuje přehlédnutí.
Teď zrovna mě nenapadá, k čemu bych to využil. Ale život mě za ta léta naučil, že umí nastolovat situace, jež nevymyslí ani ta nejbujnější fantazie. Víte, já si velmi dobře uvědomuji, jaké chyby to může způsobit, to mi tu nemusíte vykládat. Stejně jako si uvědomuji, co se může stát, když v autě přejedu dvojitou plnou čáru. V naprosté většině situací to činit nebudu. Ale dovedu si představit i situace, kdy bych to udělal, zatímco kdyby tam bylo svodidlo, tak mám situaci výrazně komplikovanější.
A proto právě máme unsafe, které to svodidlo odmontuje (v místech prokázané propasti teda nadává i tak) a dá tam jen dopravní značku. Velkou, oranžovou a s vykřičníkem.
Nicméně pointer na adresu na stacku, která už není platná, je něco co si naprosto neumím představit jako užitečnou funkci. Pokud zrovna neopravuju vesmírnou sondu na dálku a neřeším nějakou hodně hodně obskurní chybu za běhu. A to není typický příklad, který by měl programovací jazyk podporovat pohodlným způsobem. Tam jisté nepohodlí ničemu neškodí.
Suhlasim s tym, ze v embedet svete Rust neprinasa ziadnu killer feature, lebo aj tak polka kodu bude unsafe (skusal som to).
Nebude. Pokud nepíšete vnitřnosti nějakého RTOS, tak se unsafe dá celkem pohodlně vyhnout ked sa clovek nesprava ako prasa.
Skor dufam, ze sa v embedet svete presadi Zig, na low-level veci, WASM a embedet ovela zuajimavejsia volba ako Rust alebo Go.
Zig se neprosadí, nemá prakticky žádnou komerční nebo komunitní podporu ani publicitu.
A to Go jste do té skupiny asi zařadil omylem.. ten jazyk má úplně jiné cíle a vlastnosti.
-
Rozdíl mezi zkušeným profesionálem a nezkušeným začátečníkem je jen ve škodě, kterou jejich chyby způsobí. Začátečníka nikdo ke kritickým věcem bez dozoru nepustí.
I profíci dělají chyby. Dokonce i hloupé chyby. Taková Ariane nebo NASA by mohli vyprávět...
https://en.wikipedia.org/wiki/Ariane_flight_V88
https://cs.wikipedia.org/wiki/Mars_Climate_Orbiter#P%C5%99%C3%AD%C4%8Dina_ne%C3%BAsp%C4%9Bchu
A protože si složitost software a omylnost vývojářů umíme přiznat, tak máme od té doby různá povinná code review a povinné statické analýzy v překladači a mimo něj. I pro profíky.
Tak jsme se zasnili... To platilo možná někdy před 30+ lety. Už se v téhle branži pohybuji pár desítek let a bohužel musím konstatovat, že kvalita jde neustále dolů. Ani renomované společnosti často neangažují odborníky s odpovídající reálnou kvalifikací. Velmi často mě překvapuje, jak nezkušení a nedostatečně kvalifikovaní lidé často mají na starosti i poměrně kritické projekty. Tím nechci říci, že by byli hloupí, ale zkrátka na dané pozici bych si často představoval někoho lépe odborně vybaveného, kdo už má více různorodých zkušeností a má takový ten profesionální čuch. A zároveň má i odpovídající formální vzdělání. U nějakého samouka by si nikdo asi zuby spravovat nenechal. Ale v softwaru a elektronice je to dnes naprosto běžné. Takoví lidé jsou ovšem postiženi nevědomou nevědomostí, což je velmi nebezpečné. Jazyky jako Rust fachmanovi moc nepomohou, zato ho dost omezují.
To si klidně posuzujte. U Vašich vlastních projektů.
Jenže u dlouhodobých věcí to taky musí někdo udržovat. A nemusí znát všechny Vaše triky. Nebo se může ten kód portovat na novou platformu, kde nějaký invariant přestane platit.
MISRA je terčem kritiky proto, že je zastaralá a zaseklá právě u starých překladačů a verzí jazyka. Že nereflektuje nové funkce jazyků a překladačů, které usnadňují práci a zachovávají (hlídají) bezpečnost.
Taky očekává programování v notepadu bez kontrol a proto vyžaduje (otravný) styl psaní, který eliminuje přehlédnutí.
Důvodů kritiky je víc.
Moje "vlastní" projekty jsou například ty, za něž jsem momentálně odpovědný. I v C se dá psát stylem nevyžadujícím žádné triky. A kde je to žádoucí, tam je namístě komentář a zdůvodnění toho triku.
Nicméně pointer na adresu na stacku, která už není platná, je něco co si naprosto neumím představit jako užitečnou funkci. Pokud zrovna neopravuju vesmírnou sondu na dálku a neřeším nějakou hodně hodně obskurní chybu za běhu. A to není typický příklad, který by měl programovací jazyk podporovat pohodlným způsobem. Tam jisté nepohodlí ničemu neškodí.
Vzpomínám si na jednu situaci - záhadně zamrzající program za nespecifických okolností (na ARM Cortexu). Problém byl v tom, že jednomu procesu za jistých okolností přetékal zásobník k sousedovi. Samozřejmě se jako problematický jevil ten poškozený sousední proces a projevovalo se to dlouho poté, co k narušení jeho paměti došlo. Tady by se asi dala použít adresa zaniklého objektu na zásobníku jako marker, kam až zasáhl.
-
Dělám v C++ přes 20 let, mám toho za sebou hodně, a i teď se mi poraří udělat chybu, kterou odhalím až v testech, a kterou bych v Rustu nemohl udělat. Říkat, že něco nic nepřináší je prostě blbost - kdyby C++ mělo borrow checker, hned ho budu používat.
Podle mě mít safe kód v C++ není o zkušenostech, ale spíš o důkladném testování, a to je něco, na co hodně lidí zapomíná.
Nechci tím říct, že v rustu se nedají udělat chyby, ale spíš ty logické než nějaké safety chyby.
-
Rozdíl mezi zkušeným profesionálem a nezkušeným začátečníkem je jen ve škodě, kterou jejich chyby způsobí. Začátečníka nikdo ke kritickým věcem bez dozoru nepustí.
I profíci dělají chyby. Dokonce i hloupé chyby. Taková Ariane nebo NASA by mohli vyprávět...
https://en.wikipedia.org/wiki/Ariane_flight_V88
https://cs.wikipedia.org/wiki/Mars_Climate_Orbiter#P%C5%99%C3%AD%C4%8Dina_ne%C3%BAsp%C4%9Bchu
A protože si složitost software a omylnost vývojářů umíme přiznat, tak máme od té doby různá povinná code review a povinné statické analýzy v překladači a mimo něj. I pro profíky.
Tak jsme se zasnili... To platilo možná někdy před 30+ lety. Už se v téhle branži pohybuji pár desítek let a bohužel musím konstatovat, že kvalita jde neustále dolů. Ani renomované společnosti často neangažují odborníky s odpovídající reálnou kvalifikací. Velmi často mě překvapuje, jak nezkušení a nedostatečně kvalifikovaní lidé často mají na starosti i poměrně kritické projekty. Tím nechci říci, že by byli hloupí, ale zkrátka na dané pozici bych si často představoval někoho lépe odborně vybaveného, kdo už má více různorodých zkušeností a má takový ten profesionální čuch. A zároveň má i odpovídající formální vzdělání. U nějakého samouka by si nikdo asi zuby spravovat nenechal. Ale v softwaru a elektronice je to dnes naprosto běžné. Takoví lidé jsou ovšem postiženi nevědomou nevědomostí, což je velmi nebezpečné. Jazyky jako Rust fachmanovi moc nepomohou, zato ho dost omezují.
To si klidně posuzujte. U Vašich vlastních projektů.
Jenže u dlouhodobých věcí to taky musí někdo udržovat. A nemusí znát všechny Vaše triky. Nebo se může ten kód portovat na novou platformu, kde nějaký invariant přestane platit.
MISRA je terčem kritiky proto, že je zastaralá a zaseklá právě u starých překladačů a verzí jazyka. Že nereflektuje nové funkce jazyků a překladačů, které usnadňují práci a zachovávají (hlídají) bezpečnost.
Taky očekává programování v notepadu bez kontrol a proto vyžaduje (otravný) styl psaní, který eliminuje přehlédnutí.
Důvodů kritiky je víc.
Moje "vlastní" projekty jsou například ty, za něž jsem momentálně odpovědný. I v C se dá psát stylem nevyžadujícím žádné triky. A kde je to žádoucí, tam je namístě komentář a zdůvodnění toho triku.
Nicméně pointer na adresu na stacku, která už není platná, je něco co si naprosto neumím představit jako užitečnou funkci. Pokud zrovna neopravuju vesmírnou sondu na dálku a neřeším nějakou hodně hodně obskurní chybu za běhu. A to není typický příklad, který by měl programovací jazyk podporovat pohodlným způsobem. Tam jisté nepohodlí ničemu neškodí.
Vzpomínám si na jednu situaci - záhadně zamrzající program za nespecifických okolností (na ARM Cortexu). Problém byl v tom, že jednomu procesu za jistých okolností přetékal zásobník k sousedovi. Samozřejmě se jako problematický jevil ten poškozený sousední proces a projevovalo se to dlouho poté, co k narušení jeho paměti došlo. Tady by se asi dala použít adresa zaniklého objektu na zásobníku jako marker, kam až zasáhl.
S tebou bych chtel delat...
-
S tebou bych chtel delat...
Jo, no. Říkám si že možná nepotkává kvalitní programátory, protože se mu raději obloukem vyhnou.
-
Rozdíl mezi zkušeným profesionálem a nezkušeným začátečníkem je jen ve škodě, kterou jejich chyby způsobí. Začátečníka nikdo ke kritickým věcem bez dozoru nepustí.
I profíci dělají chyby. Dokonce i hloupé chyby. Taková Ariane nebo NASA by mohli vyprávět...
https://en.wikipedia.org/wiki/Ariane_flight_V88
https://cs.wikipedia.org/wiki/Mars_Climate_Orbiter#P%C5%99%C3%AD%C4%8Dina_ne%C3%BAsp%C4%9Bchu
A protože si složitost software a omylnost vývojářů umíme přiznat, tak máme od té doby různá povinná code review a povinné statické analýzy v překladači a mimo něj. I pro profíky.
Tak jsme se zasnili... To platilo možná někdy před 30+ lety. Už se v téhle branži pohybuji pár desítek let a bohužel musím konstatovat, že kvalita jde neustále dolů. Ani renomované společnosti často neangažují odborníky s odpovídající reálnou kvalifikací. Velmi často mě překvapuje, jak nezkušení a nedostatečně kvalifikovaní lidé často mají na starosti i poměrně kritické projekty. Tím nechci říci, že by byli hloupí, ale zkrátka na dané pozici bych si často představoval někoho lépe odborně vybaveného, kdo už má více různorodých zkušeností a má takový ten profesionální čuch. A zároveň má i odpovídající formální vzdělání. U nějakého samouka by si nikdo asi zuby spravovat nenechal. Ale v softwaru a elektronice je to dnes naprosto běžné. Takoví lidé jsou ovšem postiženi nevědomou nevědomostí, což je velmi nebezpečné. Jazyky jako Rust fachmanovi moc nepomohou, zato ho dost omezují.
To si klidně posuzujte. U Vašich vlastních projektů.
Jenže u dlouhodobých věcí to taky musí někdo udržovat. A nemusí znát všechny Vaše triky. Nebo se může ten kód portovat na novou platformu, kde nějaký invariant přestane platit.
MISRA je terčem kritiky proto, že je zastaralá a zaseklá právě u starých překladačů a verzí jazyka. Že nereflektuje nové funkce jazyků a překladačů, které usnadňují práci a zachovávají (hlídají) bezpečnost.
Taky očekává programování v notepadu bez kontrol a proto vyžaduje (otravný) styl psaní, který eliminuje přehlédnutí.
Důvodů kritiky je víc.
Moje "vlastní" projekty jsou například ty, za něž jsem momentálně odpovědný. I v C se dá psát stylem nevyžadujícím žádné triky. A kde je to žádoucí, tam je namístě komentář a zdůvodnění toho triku.
Nicméně pointer na adresu na stacku, která už není platná, je něco co si naprosto neumím představit jako užitečnou funkci. Pokud zrovna neopravuju vesmírnou sondu na dálku a neřeším nějakou hodně hodně obskurní chybu za běhu. A to není typický příklad, který by měl programovací jazyk podporovat pohodlným způsobem. Tam jisté nepohodlí ničemu neškodí.
Vzpomínám si na jednu situaci - záhadně zamrzající program za nespecifických okolností (na ARM Cortexu). Problém byl v tom, že jednomu procesu za jistých okolností přetékal zásobník k sousedovi. Samozřejmě se jako problematický jevil ten poškozený sousední proces a projevovalo se to dlouho poté, co k narušení jeho paměti došlo. Tady by se asi dala použít adresa zaniklého objektu na zásobníku jako marker, kam až zasáhl.
> A zároveň má i odpovídající formální vzdělání.
Jaké je podle Vás odpovídající formální vzdělání ve světě, kde se musíte neustále vzdělávat?
Vaše formální znalosti po těch desítkách let, dle mého názoru, jsou celkem na nic. To co Vás drží v práci je, že se vzděláváte. A jestli jste vystudoval medicínu, strojařinu, přírodovědu, lingvistiku, historii, nebo cokoliv jiného a jste schopen se vzdělávat, je celkem jedno.
Ten příklad se zubařem mne také pobavil protože:
Linus Torvalds, the creator of Linux, once made a famous comment comparing self-taught programmers to self-taught dentists. Here's a paraphrased version of what he said:
"I'm a big fan of education, but I'm also a big believer in self-teaching. That said, I wouldn't want to go to a self-taught dentist."
Takže klidně zůstanu jako self-taught programmer :D
-
Jaké je podle Vás odpovídající formální vzdělání ve světě, kde se musíte neustále vzdělávat?
Vaše formální znalosti po těch desítkách let, dle mého názoru, jsou celkem na nic. To co Vás drží v práci je, že se vzděláváte. A jestli jste vystudoval medicínu, strojařinu, přírodovědu, lingvistiku, historii, nebo cokoliv jiného a jste schopen se vzdělávat, je celkem jedno.
Ten příklad se zubařem mne také pobavil protože:
Linus Torvalds, the creator of Linux, once made a famous comment comparing self-taught programmers to self-taught dentists. Here's a paraphrased version of what he said:
"I'm a big fan of education, but I'm also a big believer in self-teaching. That said, I wouldn't want to go to a self-taught dentist."
Takže klidně zůstanu jako self-taught programmer :D
Jedno to rozhodně není. Stejně jako to není jedno v jiných oborech. Jako zubař-samouk si klidně vrtejte do vlastních zubů. Ale kdybyste si otevřel zubní ordinaci, asi by to bylo kvalifikováno jako pokus o ublížení na zdraví. Můj obor je průmysl a když vídám výtvory programátorů-samouků, dalo by se to často kvalifikovat úplně stejně.
Abych to upřesnil, dovedu si představit, že si doktor všeobecné medicíny udělá atestaci na zubaře, stejně jako že si matematik nebo elektrotechnik doplní relevantní znalosti z oboru vývoje SW. Ale elektrotechnikovi, který si po večerech na internetu prohlížel texty a videa o zubařině, načež si pořídil křeslo a vrtačku, bych svůj chrup rozhodně nesvěřil. Zprasený, za určitých okolností by se dalo říci i životu nebezpečný software od nedostudovaných samouků, už jsem bohužel potkal mnohokrát. Ne, že by neplatilo úsloví, že i mistr tesař se utne, ale u těch tesařů-samouků je to téměř jistota.
-
Máme procesory, na kterých běží linux za jednotky dolarů...
Osobně si myslím, že čím dál víc věcí v embedded půjde směrem, že tam bude někaký relativně hi-level os (Zephyr nebo linux) a vlastní aplikace se bude lepit nad tím v něčem, na co zrovna půjdou sehnat lidi...
Těch aplikací, které vyžadují bezpečnost/čas zase tolik nakonec není.
-
Jaké je podle Vás odpovídající formální vzdělání ve světě, kde se musíte neustále vzdělávat?
Vaše formální znalosti po těch desítkách let, dle mého názoru, jsou celkem na nic. To co Vás drží v práci je, že se vzděláváte. A jestli jste vystudoval medicínu, strojařinu, přírodovědu, lingvistiku, historii, nebo cokoliv jiného a jste schopen se vzdělávat, je celkem jedno.
Ten příklad se zubařem mne také pobavil protože:
Linus Torvalds, the creator of Linux, once made a famous comment comparing self-taught programmers to self-taught dentists. Here's a paraphrased version of what he said:
"I'm a big fan of education, but I'm also a big believer in self-teaching. That said, I wouldn't want to go to a self-taught dentist."
Takže klidně zůstanu jako self-taught programmer :D
Jedno to rozhodně není. Stejně jako to není jedno v jiných oborech. Jako zubař-samouk si klidně vrtejte do vlastních zubů. Ale kdybyste si otevřel zubní ordinaci, asi by to bylo kvalifikováno jako pokus o ublížení na zdraví. Můj obor je průmysl a když vídám výtvory programátorů-samouků, dalo by se to často kvalifikovat úplně stejně.
Abych to upřesnil, dovedu si představit, že si doktor všeobecné medicíny udělá atestaci na zubaře, stejně jako že si matematik nebo elektrotechnik doplní relevantní znalosti z oboru vývoje SW. Ale elektrotechnikovi, který si po večerech na internetu prohlížel texty a videa o zubařině, načež si pořídil křeslo a vrtačku, bych svůj chrup rozhodně nesvěřil. Zprasený, za určitých okolností by se dalo říci i životu nebezpečný software od nedostudovaných samouků, už jsem bohužel potkal mnohokrát. Ne, že by neplatilo úsloví, že i mistr tesař se utne, ale u těch tesařů-samouků je to téměř jistota.
Jožko a co by poradil mne, který má vystudované umění a pak přírodovědu (earth science) a fušuje se ti do řemesla?
mám firmu na realtime analytiku pro embedded devices. Jsem dost kvalifikován? Nestačí, že jsem schopen se s tebou bavit? Já uznávám specializace, ale ne zabedněnost. Jo a píšeme to v C, C++, Rust a OCaml/StandardML kdyby tě t zajímalo ;) Univerzitu na to abys pohledal.
-
Jožko a co by poradil mne, který má vystudované umění a pak přírodovědu (earth science) a fušuje se ti do řemesla?
mám firmu na realtime analytiku pro embedded devices. Jsem dost kvalifikován? Nestačí, že jsem schopen se s tebou bavit? Já uznávám specializace, ale ne zabedněnost. Jo a píšeme to v C, C++, Rust a OCaml/StandardML kdyby tě t zajímalo ;) Univerzitu na to abys pohledal.
Pedantický konzervativní fachidiot je hrozně komický archetyp :-) Teda dokud ho můžeš jen na dálku pozorovat.
-
Máme procesory, na kterých běží linux za jednotky dolarů...
Osobně si myslím, že čím dál víc věcí v embedded půjde směrem, že tam bude někaký relativně hi-level os (Zephyr nebo linux) a vlastní aplikace se bude lepit nad tím v něčem, na co zrovna půjdou sehnat lidi...
Těch aplikací, které vyžadují bezpečnost/čas zase tolik nakonec není.
To bude dost náročné testovat, protože tím si dovnitř zanesete obrovské množství kódu, o němž ani přesně nevíte, co dělá, z 90 % je to pro danou aplikaci nepotřebné a představuje to jen potenciální zdroj chyb a cest pro různé exploity. Je to zbytečný nárůst komplexity. Aplikací vyžadujících bezpečnost je spousta, pokud se člověk pohybuje třeba v tom průmyslu. A není-li to přímo bezpečnost, tak riziko finanční škody. Dost velkou motivací pro dodavatele SW do průmyslu by bylo, kdyby ve smlouvách standardně bylo ujednání, že když vinou chyby v SW dojde ke vzniku škod, tak to dodavatel komplet nahradí.
Jožko a co by poradil mne, který má vystudované umění a pak přírodovědu (earth science) a fušuje se ti do řemesla?
mám firmu na realtime analytiku pro embedded devices. Jsem dost kvalifikován? Nestačí, že jsem schopen se s tebou bavit? Já uznávám specializace, ale ne zabedněnost. Jo a píšeme to v C, C++, Rust a OCaml/StandardML kdyby tě t zajímalo ;) Univerzitu na to abys pohledal.
Zatím jsme se tu nijak odborně nebavili, jen tak obecně. Museli bychom se bavit o konkrétní věci. Žádnou vaši práci jsem neviděl, nejspíš jsem s vámi neměl tu čest v praxi se setkat. V čem píšete je celkem nicneříkající informace. Univerzitu na co? Pokud potřebujete univerzitu, aby vás tam naučili pracovat s vámi zmiňovanými jazyky, pak je něco špatně - to je přesně to, o čem jsem mluvil. Stačí znát obecné principy a postupy, které se více-méně od 60. let minulého století nemění. Snad všechno už tu od té doby v nějaké podobě bylo. S touto obecnou, vámi neuznávanou průpravou, zvládnete práci s nějakým konkrétním jazykem vcelku snadno. Pokud bychom oprášili ten zubařský příměr, tak je to jako práce s konkrétním materiálem nebo konkrétním nástrojem. Jenže ta podstata znalostí spočívá ve schopnosti posoudit vhodnost určitého materiálu, nástroje či postupu, umět správně diagnostikovat problém a v každém konkrétním případě umět stanovit vhodný další postup. Ne, protože jiný neznám, protože je s tím nejméně práce, nebo protože je to momentálně hype, ale protože je v daném případě optimální.
Opět z praxe - jestliže vás firma odbývá s tím, že na daném HW není možné určitou věc implementovat kvůli nedostatku paměti, a vy při nahlédnutí do programu zjistíte, že používají vnořená volání, místo aby to vyřešili pomocí stavového automatu, takže by stačila jedna stavová proměnná, jedno volání a hromada paměti by ještě zbyla, tak je asi něco špatně. Totéž jiný ekšpert - "nelze, pro daný úkol nedostatečný HW". Problém byl v tom, že místo aby kalibrační křivku implementoval pomocí interpolační tabulky a FXP aritmetiky, snažil se to realizovat přesně podle údajů z katalogu, tj. potřeboval FP knihovnu, aby mohl do programu prostě tupě opsat kalibrační vzorec. Nebo jiný "neřešitelný problém", tentokrát v assembleru - měřidlo dodává údaj ve formátu double, systém to potřebuje jako single... (btw - pomohlo by nějak dotyčným s řešením těchto problémů, kdyby používali Rust?)
A ne, řešením opravdu není použít silnější HW. Jednak to často nejde, průmyslový HW se nedá měnit jak ponožky, to jsou systémy, které mají spolehlivě a kontinuálně pracovat i desítky let a stojí to desítky, stovky milionů, a jednak neschopný vývojář vždycky dříve či později narazí na problém, na který mu daný HW nestačí, ale stačil by mu, kdyby nebyl neschopný.
-
Máme procesory, na kterých běží linux za jednotky dolarů...
Osobně si myslím, že čím dál víc věcí v embedded půjde směrem, že tam bude někaký relativně hi-level os (Zephyr nebo linux) a vlastní aplikace se bude lepit nad tím v něčem, na co zrovna půjdou sehnat lidi...
Těch aplikací, které vyžadují bezpečnost/čas zase tolik nakonec není.
To bude dost náročné testovat, protože tím si dovnitř zanesete obrovské množství kódu, o němž ani přesně nevíte, co dělá, z 90 % je to pro danou aplikaci nepotřebné a představuje to jen potenciální zdroj chyb a cest pro různé exploity. Je to zbytečný nárůst komplexity. Aplikací vyžadujících bezpečnost je spousta, pokud se člověk pohybuje třeba v tom průmyslu. A není-li to přímo bezpečnost, tak riziko finanční škody. Dost velkou motivací pro dodavatele SW do průmyslu by bylo, kdyby ve smlouvách standardně bylo ujednání, že když vinou chyby v SW dojde ke vzniku škod, tak to dodavatel komplet nahradí.
Jožko a co by poradil mne, který má vystudované umění a pak přírodovědu (earth science) a fušuje se ti do řemesla?
mám firmu na realtime analytiku pro embedded devices. Jsem dost kvalifikován? Nestačí, že jsem schopen se s tebou bavit? Já uznávám specializace, ale ne zabedněnost. Jo a píšeme to v C, C++, Rust a OCaml/StandardML kdyby tě t zajímalo ;) Univerzitu na to abys pohledal.
Zatím jsme se tu nijak odborně nebavili, jen tak obecně. Museli bychom se bavit o konkrétní věci. Žádnou vaši práci jsem neviděl, nejspíš jsem s vámi neměl tu čest v praxi se setkat. V čem píšete je celkem nicneříkající informace. Univerzitu na co? Pokud potřebujete univerzitu, aby vás tam naučili pracovat s vámi zmiňovanými jazyky, pak je něco špatně - to je přesně to, o čem jsem mluvil. Stačí znát obecné principy a postupy, které se více-méně od 60. let minulého století nemění. Snad všechno už tu od té doby v nějaké podobě bylo. S touto obecnou, vámi neuznávanou průpravou, zvládnete práci s nějakým konkrétním jazykem vcelku snadno. Pokud bychom oprášili ten zubařský příměr, tak je to jako práce s konkrétním materiálem nebo konkrétním nástrojem. Jenže ta podstata znalostí spočívá ve schopnosti posoudit vhodnost určitého materiálu, nástroje či postupu, umět správně diagnostikovat problém a v každém konkrétním případě umět stanovit vhodný další postup. Ne, protože jiný neznám, protože je s tím nejméně práce, nebo protože je to momentálně hype, ale protože je v daném případě optimální.
Opět z praxe - jestliže vás firma odbývá s tím, že na daném HW není možné určitou věc implementovat kvůli nedostatku paměti, a vy při nahlédnutí do programu zjistíte, že používají vnořená volání, místo aby to vyřešili pomocí stavového automatu, takže by stačila jedna stavová proměnná, jedno volání a hromada paměti by ještě zbyla, tak je asi něco špatně. Totéž jiný ekšpert - "nelze, pro daný úkol nedostatečný HW". Problém byl v tom, že místo aby kalibrační křivku implementoval pomocí interpolační tabulky a FXP aritmetiky, snažil se to realizovat přesně podle údajů z katalogu, tj. potřeboval FP knihovnu, aby mohl do programu prostě tupě opsat kalibrační vzorec. Nebo jiný "neřešitelný problém", tentokrát v assembleru - měřidlo dodává údaj ve formátu double, systém to potřebuje jako single... (btw - pomohlo by nějak dotyčným s řešením těchto problémů, kdyby používali Rust?)
A ne, řešením opravdu není použít silnější HW. Jednak to často nejde, průmyslový HW se nedá měnit jak ponožky, to jsou systémy, které mají spolehlivě a kontinuálně pracovat i desítky let a stojí to desítky, stovky milionů, a jednak neschopný vývojář vždycky dříve či později narazí na problém, na který mu daný HW nestačí, ale stačil by mu, kdyby nebyl neschopný.
Dnes je HW mnohem levnější, než čas vývojáře.... use case, kde se vyplatí na krev optimalizovat bude jen a jen ubývat. Tím neříkám, že nebudou, ale postupně se více a více funkcionality bude psát ve vyšších jazycích.
-
Já pravě vidím pravý opak - čás vývojáře je nic pokud je schopný optimalizovat.
Pokud píšeš aplikaci pro desktop, tak čas vývojáře je velký náklad, pokud pro servery, kde jich budeš potřebovat tisíce, tak jakákoliv optimalizace může ušetřit miliony (v USD). Čas vývojáře byl drahý než přišel cloud.
-
Dnes je HW mnohem levnější, než čas vývojáře.... use case, kde se vyplatí na krev optimalizovat bude jen a jen ubývat. Tím neříkám, že nebudou, ale postupně se více a více funkcionality bude psát ve vyšších jazycích.
Tohle do jisté míry platí na desktopu a na smartphonech. Ale tady se bavíme o embedded a průmyslových aplikacích, kde je situace dost odlišná. Navíc u těch příkladů nešlo o žádnou optimalizaci na krev. Tam šlo o to, jestli to píše někdo, kdo používá hlavu, nebo blbec.
Já osobně bych s tou neustále omílanou mantrou o levném HW a drahém času vývojáře byl opatrnější. Kdyby se posčítal zbytečně promrhaný výkon na všech zařízeních, na nichž ten neefektivní SW pracuje, tak bychom dost pravděpodobně zjistili, že ušetřený čas vývojářů nás vyšel zatraceně draho. Nehledě na to, že čas to zabere právě těm nedoukům, kteří jsou v lepším případě nuceni objevovat Ameriku, zatímco profesionál by to vysypal z rukávu na první dobrou. V horším případě prohlásí problém za neřešitelný.
-
Dnes je HW mnohem levnější, než čas vývojáře.... use case, kde se vyplatí na krev optimalizovat bude jen a jen ubývat. Tím neříkám, že nebudou, ale postupně se více a více funkcionality bude psát ve vyšších jazycích.
Tohle do jisté míry platí na desktopu a na smartphonech. Ale tady se bavíme o embedded a průmyslových aplikacích, kde je situace dost odlišná. Navíc u těch příkladů nešlo o žádnou optimalizaci na krev. Tam šlo o to, jestli to píše někdo, kdo používá hlavu, nebo blbec.
Já osobně bych s tou neustále omílanou mantrou o levném HW a drahém času vývojáře byl opatrnější. Kdyby se posčítal zbytečně promrhaný výkon na všech zařízeních, na nichž ten neefektivní SW pracuje, tak bychom dost pravděpodobně zjistili, že ušetřený čas vývojářů nás vyšel zatraceně draho. Nehledě na to, že čas to zabere právě těm nedoukům, kteří jsou v lepším případě nuceni objevovat Ameriku, zatímco profesionál by to vysypal z rukávu na první dobrou. V horším případě prohlásí problém za neřešitelný.
Ale ono se to děje přirozeně. Dneska už nikdo nebude stavět nové zařízení na nějakém 8051. My se teď třeba rozhodli opustit v produktech už poměrně staré stm32f4 ve prospěch stm32h7.... výkon, paměť a možnosti se zvýší několikrát, a při tom bude levnější (starým čipům roste cena). Už na těch f4 máme micropython, aby se jednoduché operace nad daty, co zákazníci chtěli custom, mohli od firmware oddělit a nemuselo se to udržovat....
Bývala k tomu nativní konfigurační aplikace, dneska je v tom web, protože ty procesory mají výkonu dost.
A to spíš propaguju ten konzervativnější přístup, spousta věcí už se tlačí k linuxu...
-
zatímco profesionál by to vysypal z rukávu
Tady se občas objeví tato a podobná představa.
Uvědomujete si doufám, že ono těch profesionálů a těch, co umí dobře programovat je čím dál tím méně? Že sice máte pravdu, že dobrý vývojář žádný Rust nepotřebuje (ne, není to pravda), ale je to to samé, jako když by jste hladovému Somálci poradil, ať se nají.
Kdyby se posčítal zbytečně promrhaný výkon na všech zařízeních, na nichž ten neefektivní SW pracuje, tak bychom dost pravděpodobně zjistili, že ušetřený čas vývojářů nás vyšel zatraceně draho.
A jak byste to chtěl sčítat? Toto není pravda. Tohle nikoho nebolí.
Víte kolik afričanů by se mohlo napít z potůčku, který mi teče za barákem? Ho nechávám téct úplně zbytečně. Pěkně drahý potůček.
-
Tohle do jisté míry platí na desktopu a na smartphonech. Ale tady se bavíme o embedded a průmyslových aplikacích, kde je situace dost odlišná. Navíc u těch příkladů nešlo o žádnou optimalizaci na krev. Tam šlo o to, jestli to píše někdo, kdo používá hlavu, nebo blbec.
..
Kdyby se posčítal zbytečně promrhaný výkon na všech zařízeních, na nichž ten neefektivní SW pracuje, tak bychom dost pravděpodobně zjistili, že ušetřený čas vývojářů nás vyšel zatraceně draho.
Embedded zahrnuje masově vyráběné jednorázové hračky i kusovou výrobu pro konkrétní speciální případ (třeba satelity). Nemůžete obojí hodit do stejného pytle, protože ty firmy optimalizují na úplně jiné metriky.
Můžete optimalizovat na určitou kombinaci
čas do nasazení - rychle něco vyrobit a získat trh, optimalizace se dělají dodatečně nebo vůbec, trošku vyšší cena hardware může být bohatě kompenzována náskokem před konkurencí.
cena podpory - optimalizace se opět dělají málo nebo vůbec, protože požadavky zákazníka se často mění a je potřeba umět rychle reagovat, proto je dneska většina věcí software-defined-něco. Software se upgraduje snáz, než hardware.
Oproti tomu můžete taky optimalizovat na druhý protipól
náklady na vývoj - absolutně co nejnižší cena za kus - levné cpu, levný vývoj, protože spotřební elektronika a nulová podpora
Ani jedno z toho nevyžaduje optimalizaci a super schopného génia, který zná všechny kličky.
Dokonale spolehlivý software je potřeba pro místa, kde se nedá dělat servis nebo musíte garantovat dekádu provozu bez problémů a certifikace. Letectví, vesmír, lékařství... o trošku méně automotive, možná těžaři a nebezpečné průmyslové provozy.
Ale pořád to nemusí být optimalizovaný software, naopak, může být výhodnější napsat jednodušší software (super loop s minimem podmínek) a "matematicky" dokázat jeho spolehlivost než ladit každou ztracenou mikrosekundu nebo pár byte paměti (za spolehlivost se platí a dražší čip se už v té ceně ztratí).
Když děláme real time, tak průmysl ani nepotřebuje lepší RTT, než zhruba milisekundu. Telekomunikace jsou horší, ti chtějí max desítky mikrosekund.
Absolutní optimalizaci dělají tak možná filmová a herní studia, která potřebují nacpat novou hru s lepšími efekty na existující hardware nebo konzoli. Případně ten film vyrenderovat dřív než lidi ztratí zájem. A i ti si ten 3D engine koupí a dodělají detaily, protože je to levnější.
Takže ne, optimalizace výkonu a zabraného místa dávno není prioritou, pokud nejsou speciální požadavky. Typicky je mnohem důležitější cena vývoje (včetně platu vývojářů), čas pro nasazení a efektivita podpory a oprav na místě.
-
naopak, může být výhodnější napsat jednodušší software (super loop s minimem podmínek) a "matematicky" dokázat jeho spolehlivost než ladit každou ztracenou mikrosekundu nebo pár byte paměti (za spolehlivost se platí a dražší čip se už v té ceně ztratí).
Ano, to se běžně dělá, i v tom space segmentu. Casto se vlastní algorimus dela necem typu simulink nebo nejaký podobný nástroj a pak se to jen nějakou formou vkládá do už ověřeného prostředí.
Efektivní to není ani náhodou, ale dá se to dobře testovat (nekdy včetně formální verifikace).
-
Víte kolik afričanů by se mohlo napít z potůčku, který mi teče za barákem? Ho nechávám téct úplně zbytečně. Pěkně drahý potůček.
Přirovnání s potůčkem kulhá na všechny čtyři. Lepší přirovnání by spíš bylo s kohoutky, do kterých se nevyplatí dávat těsnění, protože je to moc práce, když vody je přece dost, takže nebude vadit, když si větší či menší čůrek pitné vody z každého kohoutku poteče jen tak nazdařbůh do kanálu. Ale zároveň všude do mě budou tlačit, ať šetřím vodou, nesprchuji se moc dlouho a omezovat velikost kbelíků.
To, že aplikace na mobilní bankovnictví by se ani nevešla na můj první harddisk a z deseti spuštění se tak jednou kousne, mi opravdu nepřipadá jako uspokojivý stav věcí.
-
mi opravdu nepřipadá jako uspokojivý stav věcí.
To je vám ke cti (ve skutečnosti s vámi do určité míry souzním), ale to je asi tak to jediné pozitivní, co se na tom dá najít.
Rovnice je jednou daná, a nemá smysl být nešťastný, že byste chtěl, aby dávala jiné výsledky.
-
mi opravdu nepřipadá jako uspokojivý stav věcí.
To je vám ke cti (ve skutečnosti s vámi do určité míry souzním), ale to je asi tak to jediné pozitivní, co se na tom dá najít.
Rovnice je jednou daná, a nemá smysl být nešťastný, že byste chtěl, aby dávala jiné výsledky.
No jo, to je ovšem zase takový ten přístup jak zpíval Werich, "tohle člověk nezmění, to je bóží řízení..."
Na běžných zařízeních mě to zase tak netrápí, i když ve světle zákazů žárovek, omezování výkonů vysavačů, varných konvic, připojování víček k PET lahvím, zákazům brček a uchošťourů atp. mě překvapuje, že tohle nikdo neřeší. Ale trápí mě to v tom průmyslu, kdy nároky kladené na řídící a automatické kontrolní systémy se kvůli úsporám na zaměstnancích, snaze tlačit všechno na hranu, a v energetice navíc ještě připojováním mikrozdrojů, neustále zvyšují, ale jejich kvalita a spolehlivost neustále klesá. Prostě nejsem ten typický lumík, co nadšeně kráčí do propasti s davem ostatních. A i kdyby mě ten dav nakonec ušlapal, můžu si říci-aspoň jsem zkusil se proti tomu postavit. Stavět se na odpor hlouposti je podle mě morální povinnost každého rozumného člověka.
-
Dokonale spolehlivý software je potřeba pro místa, kde se nedá dělat servis nebo musíte garantovat dekádu provozu bez problémů a certifikace. Letectví, vesmír, lékařství... o trošku méně automotive, možná těžaři a nebezpečné průmyslové provozy.
Ale pořád to nemusí být optimalizovaný software, naopak, může být výhodnější napsat jednodušší software (super loop s minimem podmínek) a "matematicky" dokázat jeho spolehlivost než ladit každou ztracenou mikrosekundu nebo pár byte paměti (za spolehlivost se platí a dražší čip se už v té ceně ztratí).
Tato oblast mě zajímá a reaguji na informaci o matematickém dokázání spolehlivosti. Mám velmi rád programovací jazyk Ada, kde se právě pro toto prokázání používá nástroj Spark. Dle dokumentace od Adacore jej však nelze využít pro C/C++/Rust, cituji: "Kódu psanému v C/C++ nebo Rustu se SPARK použít nedá – nejvýš můžete ze SPARKu volat funkce napsané v C a těm pak důvěřovat nebo je testovat klasickými postupy, ale matematický důkaz vlastností pro ně SPARK nevede.". Umělá chytrost mi nabízí možnosti Frama-C + ACSL/WP, CBMC pro C++ nebo Prusti pro Rust, využíváte některou z nich?
-
Víte kolik afričanů by se mohlo napít z potůčku, který mi teče za barákem? Ho nechávám téct úplně zbytečně. Pěkně drahý potůček.
Přirovnání s potůčkem kulhá na všechny čtyři. Lepší přirovnání by spíš bylo s kohoutky, do kterých se nevyplatí dávat těsnění, protože je to moc práce, když vody je přece dost, takže nebude vadit, když si větší či menší čůrek pitné vody z každého kohoutku poteče jen tak nazdařbůh do kanálu. Ale zároveň všude do mě budou tlačit, ať šetřím vodou, nesprchuji se moc dlouho a omezovat velikost kbelíků.
To, že aplikace na mobilní bankovnictví by se ani nevešla na můj první harddisk a z deseti spuštění se tak jednou kousne, mi opravdu nepřipadá jako uspokojivý stav věcí.
Úplně běžná věc, se kterou si většina svět neláme hlavu.
Třeba v US se staví levné a jednoduché domy, kdy třeba na jihu pak jede 24/7 klimatizace, a na jednovrstvém okně máte většinu času rozdíl teplot klidně 20K. A nikoho to nesere, domy jsou levné a střední třídě dostupné, a energie taky (0.13 USD KWh koncově, už 30 let, tzn. inflací stále zlevňuje). Roční spotřeba takového domu je 30-40MWh, ale všichni jsou s tím spokojení. Ani FVE se nedelá, i když by se výkon časově kryl s maximem spotřeby.
Tohle je prostě jen Evropské brečení, jinde jsou větší pragmatici.
-
Dokonale spolehlivý software je potřeba pro místa, kde se nedá dělat servis nebo musíte garantovat dekádu provozu bez problémů a certifikace. Letectví, vesmír, lékařství... o trošku méně automotive, možná těžaři a nebezpečné průmyslové provozy.
Ale pořád to nemusí být optimalizovaný software, naopak, může být výhodnější napsat jednodušší software (super loop s minimem podmínek) a "matematicky" dokázat jeho spolehlivost než ladit každou ztracenou mikrosekundu nebo pár byte paměti (za spolehlivost se platí a dražší čip se už v té ceně ztratí).
Tato oblast mě zajímá a reaguji na informaci o matematickém dokázání spolehlivosti. Mám velmi rád programovací jazyk Ada, kde se právě pro toto prokázání používá nástroj Spark. Dle dokumentace od Adacore jej však nelze využít pro C/C++/Rust, cituji: "Kódu psanému v C/C++ nebo Rustu se SPARK použít nedá – nejvýš můžete ze SPARKu volat funkce napsané v C a těm pak důvěřovat nebo je testovat klasickými postupy, ale matematický důkaz vlastností pro ně SPARK nevede.". Umělá chytrost mi nabízí možnosti Frama-C + ACSL/WP, CBMC pro C++ nebo Prusti pro Rust, využíváte některou z nich?
Já používám formální analýzu výjímečně a vlastně pouze v FPGA designech, v místech, kde se řeší střet více hodinových domén.... většinou nad VHDL, což je de fakto ADA.
-
Já pravě vidím pravý opak - čás vývojáře je nic pokud je schopný optimalizovat.
Pokud píšeš aplikaci pro desktop, tak čas vývojáře je velký náklad, pokud pro servery, kde jich budeš potřebovat tisíce, tak jakákoliv optimalizace může ušetřit miliony (v USD). Čas vývojáře byl drahý než přišel cloud.
Tohle, a možná ještě nějaký hlubší lowpower jsou jediné aplikace, kde jsem se setkal s tím, že to někdo ocení...
Jo, AVX-2 v asm, to byla zábava :D Ale smysl to mělo zatím přesně jednou.
-
mi opravdu nepřipadá jako uspokojivý stav věcí.
To je vám ke cti (ve skutečnosti s vámi do určité míry souzním), ale to je asi tak to jediné pozitivní, co se na tom dá najít.
Rovnice je jednou daná, a nemá smysl být nešťastný, že byste chtěl, aby dávala jiné výsledky.
No jo, to je ovšem zase takový ten přístup jak zpíval Werich, "tohle člověk nezmění, to je bóží řízení..."
...
A i kdyby mě ten dav nakonec ušlapal, můžu si říci-aspoň jsem zkusil se proti tomu postavit. Stavět se na odpor hlouposti je podle mě morální povinnost každého rozumného člověka.
To si nerozumíme. To není v tom, že je to boží řízení. To je v tom, že vy neumíte počítat. Já vám opravdu nezaplatím x $ za to, abyste vy měl pocit, že je to správně.
Možná ještě příklad:
Já když budu chtít vytvořit projekt, a budu poptávat vývojáře, tak vyrazím dveře s vývojářem, který mi bude tvrdit, že v C to napíše lépe, ekonomičtěji, než to by to napsal nědo jiný v Rustu. Když vím, že ten C vývojář bude desetkrát dražší, zatímco to Rust programátor to udělá líp, i když bude méně zkušenej, a výsledný kód bude měně optimální, což se mi do ceny nepromítne.
-
To si nerozumíme. To není v tom, že je to boží řízení. To je v tom, že vy neumíte počítat. Já vám opravdu nezaplatím x $ za to, abyste vy měl pocit, že je to správně.
Možná ještě příklad:
Já když budu chtít vytvořit projekt, a budu poptávat vývojáře, tak vyrazím dveře s vývojářem, který mi bude tvrdit, že v C to napíše lépe, ekonomičtěji, než to by to napsal nědo jiný v Rustu. Když vím, že ten C vývojář bude desetkrát dražší, zatímco to Rust programátor to udělá líp, i když bude méně zkušenej, a výsledný kód bude měně optimální, což se mi do ceny nepromítne.
Ano, mohli bychom se tu vzájemně obviňovat z toho, že já neumím počítat a vy zase, že jste fanatický zastánce Rustu. Nevím, kolik vám je, ale pro mě je to už třetí hype, jehož jsem svědkem-nejdřív zázračné C++, pak zázračná Java a teď zázračný Rust. Nevím, kde jste vzal nesmysl, že nezkušený vývojář v Rustu něco udělá lépe a levněji než průměrný vývojář v C (C++, Javě, Go, Pascalu, whatever...). Sorry, ale tohle už je nějaké náboženství-jak ty články, že něco je napsané v Rustu (sláva!), někdo něco přepsal do Rustu (Rust rulez!), někdo se rozhodl zastavit projekt v Rustu (hanba mu, špatné rozhodnutí bez ohledu na fakta)...
Původní dotaz byl na budoucnost Rustu v embedded světě. Můj názor je, že momentálně je to spíše marginální záležitost a že se na tom nejspíš v blízké budoucnosti nic nezmění. Ve vzdálenější zas někdo přijde s něčím jiným, módnějším, "modernějším", až se opět ukáže, že programy v Rustu nejsou víc sexy, než kdyby byly napsány v čemkoli jiném. Důvodem je, že Rust nepřináší nic tak zásadního, jako bylo C oproti assembleru, a není to ani "(eko)systémový jazyk", jako je tomu v Unixu, z něhož se přirozeně rozšiřovalo dál. Ono i to C++ je v embedded světě takové rozpačité, spousta kódu co jsem v této oblasti viděl na mě působí dojmem upachtěného OOP, tj. vymyslím nějak třídy a objekty, i když to v dané situaci vůbec nic nepřináší, jen více kódu a nepřehlednosti. Prostě mnou kritizovaná bezhlavá grafománie.
Asi bych Rust doporučoval místo C++. Ale zároveň bych vážil, zda v dané situaci neexistuje ještě příhodnější možnost, např. kombinace více jazyků s rozvrstvením do více úrovní/modulů. Ale to už opět míří spíše na desktopy a servery.
-
Nevím, kde jste vzal nesmysl, že nezkušený vývojář v Rustu něco udělá lépe a levněji než průměrný vývojář v C (C++, Javě, Go, Pascalu, whatever...).
že programy v Rustu nejsou víc sexy, než kdyby byly napsány v čemkoli jiném. Důvodem je, že Rust nepřináší nic tak zásadního, jako bylo C oproti assembleru..
Jenže napíše a přináší. Rust přináší nejlépe integrovanou statickou analýzu, jakou jsme dosud pro nízkoúrovňové programování měli k dispozici. Tudíž i ten nezkušený vývojář se vyhne spoustě paměťových a souběhových chyb.
Nemluvě o tom, jak vypadají chybová hlášení překladače v Rustu a C/C++. Viděl jste někdy, jak moc Vás to navádí k tomu, co máte opravit?
Pro C/C++ existují nástroje na statickou analýzu, ale nikdy nebyly tak pohodlné a integrované. To samé infrastruktura kolem unit testů a vůbec správy závislostí.
Rust se prostě objevil ve vhodnou chvíli a hodně zvedl komfort a jistotu při vývoji. Nic nového na této úrovni zatím na obzoru není. Naopak Rust má za sebou firmy jako Ferrocene a díky ní i certifikaci překladače pro kritické systémy.
-
Rust se prostě objevil ve vhodnou chvíli a hodně zvedl komfort a jistotu při vývoji. Nic nového na této úrovni zatím na obzoru není.
Bylo to naprosté zjevení.
Jazyk se zárukama na úrovni Haskellu s výkonem na úrovni C? Jazyk s nástroji jako enterprise Java? Se nedivím, že tomu člověk nechce uvěřit.
Toto vlákno je zajímavé i tím, že jsem si do teď myslel, že embedded je taková poslední bašta, kde má smysl jazyky jako C používat, právě proto, že se tam šíbuje ještě na úrovni assembleru. Ale překvapuje mě, že zřejmě ne.
-
Já používám formální analýzu výjímečně a vlastně pouze v FPGA designech, v místech, kde se řeší střet více hodinových domén.... většinou nad VHDL, což je de fakto ADA.
Moc děkuji za odpověď, VHDL jsem neznal. Cvičně jsem si nechal umělou chytrostí vygenerovat nějaký ten kód a vidím známou syntaxi s is - begin - end. Podobně jsem postupoval i u PL/SQL který je na tom podobně, jsem rád, že deriváty mého oblíbeného jazyka existují a stále se používají.
-
Jazyk s nástroji jako enterprise Java?
Tomuhle nerozumim. Nemel bys priklad nebo dva?
-
Jazyk s nástroji jako enterprise Java?
Tomuhle nerozumim. Nemel bys priklad nebo dva?
Tak třeba Java má Maven, Haskell má Cabal, Rust má Cargo.
Java má junit, Haskell má cabal test (hunit, QuickCheck, Hedgehog), Rust má Cargo test
Java má Checkstyle, PMD, SpotBugs, SonarQube; Haskell má HLint, Weeder; Rust má Clippy, Rustfmt
No, C má samozřejmě make. Což je v souladu s filozofií C: udělej si sám.
Těch nástrojů je přirozeně mnohem víc, ale já narážel na nástroje, které jsou součástí "balení", s důrazem na správu závislostí. Ta je v C tak nějak nic. Narazil jsem na nějaký Conan a Hunter - což vidím poprvé. Je rozšířené Meson, což je celkem fajn. Ale nic co by se jen vzdáleně podobalo cargu, cabalu, nebo mavenu.
-
A jo takhle. Ja myslel, ze kdyz mluvis o "enterprise" tak ze je to o https://www.oracle.com/java/technologies/java-ee-glance.html (https://www.oracle.com/java/technologies/java-ee-glance.html)
A uz sem hledal JPA, CDI, JTA, JAX-RS a podobne u rustu...
-
A jo takhle. Ja myslel, ze kdyz mluvis o "enterprise" tak ze je to o https://www.oracle.com/java/technologies/java-ee-glance.html (https://www.oracle.com/java/technologies/java-ee-glance.html)
A uz sem hledal JPA, CDI, JTA, JAX-RS a podobne u rustu...
Tak to sorry za zmatení.
Na druhou stranu k tomu, o čem mluvíš, tak jsem toho pro Rust našel překvapivě dost alternativ. Spoustu z nich ale v alfa verzi vývoje nutno podotknout.
Proti Javě, natož C je samozřejmě Rust strašný mládě. To je nutno brát. A opět, v Rustu píšou většinou schopnější lidi, plus stojí na ramenou předchůdců, takže i když je to alfa, tak bejvá dost dobrá.
- JPA: Diesel, SeaORM
- CDI: shaku
- JAX-RS: Actix Web, Axum, Rocket
-
A opět, v Rustu píšou většinou schopnější lidi
Máte k tomu nejaký relevantný podklad?
Myslím, že objektívne by ste to mohli byť schopní posúdiť až keby sa stalo, že by všetci, ktorí píšu v C a v C++, boli nútení prejsť na Rust.
Vlastne by to mohlo byť veľmi zaujímavé porovnanie.
To, že niekto ostáva s C alebo s C++ nemusí znamenať, že je menej schopný, ale to, že softvér, ktorý ho zaujíma sa píše v tých jazykoch.
-
A opět, v Rustu píšou většinou schopnější lidi
Máte k tomu nejaký relevantný podklad?
Myslím, že objektívne by ste to mohli byť schopní posúdiť až keby sa stalo, že by všetci, ktorí píšu v C a v C++, boli nútení prejsť na Rust.
Vlastne by to mohlo byť veľmi zaujímavé porovnanie.
To, že niekto ostáva s C alebo s C++ nemusí znamenať, že je menej schopný, ale to, že softvér, ktorý ho zaujíma sa píše v tých jazykoch.
Myslím, že BoneFlute myslel "schopnější než průměr", spíš než "schopnější než v C/C++"...
-
A opět, v Rustu píšou většinou schopnější lidi
Máte k tomu nejaký relevantný podklad?
Myslím, že objektívne by ste to mohli byť schopní posúdiť až keby sa stalo, že by všetci, ktorí píšu v C a v C++, boli nútení prejsť na Rust.
Vlastne by to mohlo byť veľmi zaujímavé porovnanie.
To, že niekto ostáva s C alebo s C++ nemusí znamenať, že je menej schopný, ale to, že softvér, ktorý ho zaujíma sa píše v tých jazykoch.
Myslím, že BoneFlute myslel "schopnější než průměr", spíš než "schopnější než v C/C++"...
Přesně tak. Někdo, kdo dokáže napsat dobrý kód v C, nebo C++ je bez pochyby velmi dobrý programátor.
U Rustu je problém v tom, že v něm dokáže napsat dobrý kód každý, kdo ho v Rustu dokáže napsat.
-
Přesně tak. Někdo, kdo dokáže napsat dobrý kód v C, nebo C++ je bez pochyby velmi dobrý programátor.
U Rustu je problém v tom, že v něm dokáže napsat dobrý kód každý, kdo ho v Rustu dokáže napsat.
Trošku bych to zmírnil - naprasit špatně udržovatelný kód se dá prakticky všude. Jsou ale jazyky, které hodně ztěžují vytvoření některých chyb v návrhu. C je těsto nebo hlína, ze které(ho) se dá uplácat prakticky cokoli a je mu to jedno. Rust je partner, který klade nepříjemné otázky a brání se (ale zase na druhou stranu v mnoha věcech pomáhá - od vrstev abstrakce až po build system).